Inplace Edit

Demo & usage

More examples

<sv-inplace-edit
  label="Display name"
  [value]="name()"
  [saving]="pending()"
  [error]="failure()"
  (save)="persist($event)" />

<sv-inplace-edit
  label="Status"
  mode="select"
  [options]="STATUSES"
  [(value)]="row.status"
  (save)="patch(row.id, $event)" />

<sv-inplace-edit label="Notes" mode="textarea" [rows]="4" [(value)]="notes" />

<sv-inplace-edit
  label="Project name"
  [(value)]="name"
  [conflict]="conflict()"
  (saveRequest)="save($event)"
  (conflictResolved)="resolve($event)" />

save(e: InplaceEditSave): void {
  this.api.rename(e.value, e.requestKey).subscribe({
    error: (err) => {
      // A 409 is not a failure to report — it is a question to ask.
      if (err.status === 409) { this.conflict.set({ theirs: err.error.current, by: err.error.by }); return; }
      e.rollback();
      this.error.set('Could not save that.');
    },
  });
}

<sv-inplace-edit
  label="Workspace ID"
  value="ws_8f21c4"
  lockReason="Only an administrator can change this" />

<sv-inplace-edit
  label="Display name"
  [(value)]="name"
  [saving]="pending()"
  [error]="failure()"
  (saveRequest)="persist($event)" />

When to use

• A read-mostly field the user occasionally corrects — a display name, a note, a status cell.
• You want the page to stay a page rather than becoming a form with a Save button at the bottom.
• For a screenful of fields being filled in together, use a real form; inline editing is for changing one thing.

Async states

• empty
• error

Server writes

Writes

• saveRequest

Each payload carries a requestKey — send it with the request so a retry cannot apply the same change twice.

Rollback

Call event.rollback() when the save fails — the change is already on screen, and this is what puts it back.

While saving

Bind saving — with two writes outstanding there is no single state to roll back to, so the action stays locked until the first one lands.

On failure

Pass the failure to error to show it in place — without taking away what the user was working on.

Outputs

Customization & theming

• Pick the editor with `mode` (text · textarea · select), size it with `size` and `rows`, and constrain it with `maxlength` and `required` / `requiredMessage`.
• Choose how the read view offers itself with `trigger`: `auto` (default) shows a pencil on hover or focus and always on a touch screen; `click` is the value alone with a hover underline, right for a dense table but with no affordance at all on a phone; `button` shows the pencil everywhere. Word the blank state with `emptyText`.
• Drive the save lifecycle with `saving` and `error`, and handle `(saveRequest)` for a `{ value, previous, requestKey, rollback }` payload when a server has to agree; two-way bind `[(editing)]` to open the editor from a row action of your own.
• `conflict` turns the editor into a two-value choice when someone else changed the field; `lockReason` renders it as text with an explanation and no way in.
• `commitOnBlur` decides whether an outside click saves or discards.

Best practices

• Do: Pass `label` — the read view is a button whose text is the VALUE, so without it a screen reader announces the value and never says what pressing it edits.
• Do: Hand `error` back on a failed save rather than showing only a toast; the editor re-opens with what the user typed.
• Do: Word `emptyText` for the field ("Add a bio"), since that is the only thing to click when the value is blank.
• Do: Bind `[saving]` for the whole round-trip. It is the lock that makes `rollback()` unambiguous: with two writes outstanding there is no single previous state to return to.
• Do: Answer a 409 with `[conflict]`, not with `[error]`. A conflict is a question for the user, not a failure to report — and the two need different UI because they need different decisions.
• Do: Say why a field is locked with `lockReason` rather than reaching for `disabled`. A disabled field is a dead end, and the guess users most often make about one is that the page is broken.
• Tip: Set `commitOnBlur=false` for a field where an accidental outside click should not save.
• Don't: Don't use `select` mode for a long list — it is a native picker, not a searchable dropdown. Use Select Dropdown in a form for that.

Accessibility

• The read view is a real `<button>`, named `Edit <label>` so the announcement says what pressing it does — not just the value it happens to contain.
• Enter commits and Escape reverts; in `textarea` mode Enter inserts a newline and Ctrl/Cmd+Enter commits, so a multi-line field can hold multiple lines.
• Escape stops propagating, so an inline edit inside a dialog or menu cancels the edit rather than closing what surrounds it.
• Leaving edit mode returns focus to the trigger when the editor still had it — and leaves focus alone when the user clicked another field, so it is never yanked back.
• A refused `required` commit renders a `role="alert"` message that the editor points at via `aria-describedby`, with `aria-invalid` set.
• The default `trigger="auto"` renders its pencil ALWAYS on a coarse pointer. Tailwind compiles `hover:` to `@media (hover: hover)`, so a hover-only affordance does not render faintly on a phone — it does not render at all, and the field is indistinguishable from plain text. The pencil is `aria-hidden`: the value button beside it already carries the name and offers the same action, and two tab stops onto one field is worse than none.
• A conflict is a labelled `role="group"` with a `role="alert"` sentence naming who changed it and when, then both values as text with a button each. Nothing is auto-selected — the whole point is that only the person present can decide.
• A `lockReason` is linked to the value with `aria-describedby`, so the explanation is announced with the field rather than found by accident.