Inline Edit

Turns a displayed value into an editor in place and back again. The reader stays where they are — no dialog, no separate form page — and nothing is written until they confirm.

Not for a yes/no value. Reach for toggle there: the control is already its own read state, so the confirm/cancel machinery buys nothing and costs two extra tab stops per row. This component earns its weight when the value is text a reader has to type — and only then.

Basic Usage

<x-wirekit::inline-edit name="title" label="Project title" value="Quarterly report" context="Q3 planning" />

The component does not save anything. It emits an event when the reader confirms, and your Livewire component decides what that means:

<x-wirekit::inline-edit
    name="title"
    label="Project title"
    :value="$post->title"
    :context="$post->reference"
    wire:wirekit:inline-edit-confirmed="save($event.detail.value)" />

public function save(string $value): void
{
    $this->post->update(['title' => $value]);

    // Tell the component it worked. It does NOT infer this from the round trip
    // ending — a validation failure ends one too.
    $this->dispatch('wirekit:inline-edit-saved', name: 'title');
}

Livewire compiles any non-reserved wire:<event> into an Alpine listener, so no wrapping element is needed.

The editor stays open until the save is confirmed

This is the part worth reading twice. When the reader confirms, the component enters a saving state and waits. It closes when you say the save succeeded, and not before.

That is deliberate: the end of a round trip is not evidence of success. A validation failure completes a request too, and a component that closed there would discard the error message you just rendered, leaving the reader looking at their old value with no explanation.

Three ways the outcome is reported:

Filter by name in the event detail when a page holds several editors.

Livewire

The component owns the interaction; your component owns the write. It emits wirekit:inline-edit-confirmed with name, value and previous, and waits.

Do not bind the draft two-way. A wire:model on the control writes on every keystroke, which leaves nothing to confirm and nothing for cancel to restore. The draft stays local until the reader commits — that is the whole design, not an optimization.

Validation errors

A validation failure comes back as re-rendered HTML with a filled error bag, not as a transport error. The component reads the bag under the field's name, keeps the editor open, links the message with aria-describedby, and announces it:

public function save(string $value): void
{
    $this->validate(['title' => 'required|max:120'], [], ['title' => $value]);
    // On failure Livewire re-renders and the bag is filled — nothing else to do.

    $this->post->update(['title' => $value]);
    $this->dispatch('wirekit:inline-edit-saved', name: 'title');
}

Surviving a morph

A Livewire morph must not close an open editor or lose a draft. Three rules make that hold, and all three are in the component already:

• The mode switch uses x-show, not x-if. Livewire stops patching attributes while a visibility state differs, so x-show survives; x-if would tear the open editor down mid-edit.
• Nothing server-rendered sits on the element that toggles. An id or an aria-busy there would stop being updated by the morph.
• There is no wire:ignore on the root — it would cut the error text and the displayed value off from updates too.

Add wire:key when you render these in a loop, so a morph keeps each editor attached to its own row.

Several editors at once

exclusive (default true) closes any other open editor when one opens. Without it a reader can carry ten unsaved drafts, and a wire:navigate takes all ten with it. If you turn it off, the browser still warns before a navigation that would discard an open draft.

Affordance

Two independent choices: what the reader sees, and what opens the editor.

<x-wirekit::stack gap="md">
    <x-wirekit::inline-edit name="always" label="always — the pencil is always there" value="Visible affordance" />
    <x-wirekit::inline-edit name="hover" label="hover — appears on pointer, forced visible on focus and touch" value="Quieter in a dense table" trigger="hover" />
    <x-wirekit::inline-edit name="focus-only" label="focus-only — nothing until it is tabbed to" value="Quietest of the three" trigger="focus-only" />
</x-wirekit::stack>

There is deliberately no way to remove the button. Plain text is not focusable, so a value with no button cannot be reached by keyboard at all. focus-only gives the quiet appearance without that defect: nothing is shown until the reader tabs to it, and then it is a real, visible, full-size button.

openOnValueClick (default true) makes the value itself clickable. It is a separate switch because it answers a different question, and the value never becomes the button — a button named Jane Doe tells a screen-reader user nothing about what it does, and giving a control a name that is not its visible text breaks voice control.

Two behaviors follow from that clickable value, and both only show up on a real page:

• Dragging across the value selects text, it does not open the editor. Selecting requires moving the mouse, so a movement beyond a few pixels is read as a selection.
• A link inside the value follows the link. Otherwise the link would be unreachable by mouse.

When nothing answers

The confirmation is an event. If your handler never dispatches wirekit:inline-edit-saved or wirekit:inline-edit-failed — you forgot the paired event, the request died, the tab lost its connection — the editor would otherwise stay busy forever.

It does not. After save-timeout milliseconds (default 10000) the component stops waiting and reports, in its live region, that the save was not confirmed. It says exactly that, and deliberately not that it failed: a missing acknowledgment is not evidence that the write did not happen, and telling a reader it failed invites them to edit a value that was already stored.

The editor stays open with the text still in it. Nothing the reader typed is thrown away on the strength of a guess.

Where focus goes

Focus is decided by how the reader left, not by whether the save worked:

Clicking away also discards the draft

Leaving the control without confirming closes the editor and drops what was typed, restoring the value the field had before. It is the same outcome as Escape, reached a different way. The rich-text recipe is the one exception: it binds no blur, so its draft stays open.

That is the reason commitOn exists. The default explicit means nothing is written until the reader confirms — so a click into the next field cannot save half a thought, and the price of that guarantee is that the half-thought is not kept either. Set commitOn="blur" when moving away should save instead of discard.

A round trip is not a departure. A wire:poll, a save elsewhere on the page, or any other morph blurs a focused control for an instant while the DOM is patched, and the editor stays open with the draft intact — see Surviving a morph. Only a reader who really moves focus somewhere else loses it.

What you can edit

Four built-in types, chosen with control. Each one edits in place the same way — only the control inside the open editor differs.

Anything else goes through the editor slot — a date picker, a tags input, a combobox — so an uncovered type never has to wait for a release.

<x-wirekit::stack gap="lg">
    <x-wirekit::inline-edit
        name="title"
        label="Title (text)"
        value="Quarterly report"
    />

    {{-- Long enough to actually wrap. The previous value said it "wraps onto more
         than one line" and fitted on one, so the demo contradicted its own copy and
         a textarea looked indistinguishable from a text input. --}}
    <x-wirekit::inline-edit
        name="summary"
        label="Summary (textarea)"
        control="textarea"
        value="Multi-line values are what this control is for: release notes, an internal handover, the paragraph nobody wants to retype in a modal. Reading mode keeps the text where it sits on the page, and opening the editor gives you the same box with a real textarea in it — same width, several rows tall, so the wrapping you see while reading is the wrapping you get while typing."
    />

    <x-wirekit::inline-edit
        name="seats"
        label="Seats (number)"
        control="number"
        value="12"
        min="0"
        step="1"
    />

    <x-wirekit::inline-edit
        name="status"
        label="Status (select)"
        control="select"
        value="review"
        display-value="In review"
        :options="['draft' => 'Draft', 'review' => 'In review', 'done' => 'Done']"
    />
</x-wirekit::stack>

Bringing your own control

The editor slot covers everything the four types above do not, so an uncovered type never has to wait for a release:

<x-wirekit::inline-edit name="tags" label="Tags" :value="$post->tags">
    <x-slot:editor>
        <x-wirekit::tags-input x-ref="control" x-model="draft" />
    </x-slot:editor>
</x-wirekit::inline-edit>

The slot compiles inside the component's own Alpine scope, so draft, commit() and cancel() resolve with nothing threaded in. In exchange there is a contract, and it is checked rather than assumed — in development a missing ref is reported by name:

1. Bind x-model="draft". That is the value the component commits.
2. Set x-ref="control". Focus placement and the accessibility wiring both aim at it; without it they simply do nothing. It works on a WireKit component as well as on a plain element: focus then goes to the part of the component that takes text, and the hint and error are attached there.
3. Handle Escape yourself if your control is composite (a combobox, a multi-select). Two handlers for one key make one keypress do two things — the first Escape should close your list, the second should cancel the edit.
4. Label it once. Either your control carries the label or this component does. Both means a duplicate announcement. With label and no name of its own, the part of your control that takes focus is named by the visible label when the editor opens, through aria-labelledby, and a click on the label focuses it while the editor is open. A control that names itself keeps its name: an aria-label, an aria-labelledby or a <label> of its own wins, the way a caller's aria-label wins on a built-in field. The editor always names itself, so the recipe below gives it the label's words.
5. Keep it out of a surrounding form while the editor is closed. The editor stays on the page while the value is shown, and a form checks every field it owns, shown or not. A required control of yours with an empty draft would stop a form around the component from submitting, and the browser cannot focus a hidden field to say why. Bind its disabled to the open state, as the built-in controls do: x-bind:disabled="!editing".

Rich text

Rich text is not one of the four built-in types, and that is deliberate. Its editing mode is a full editor with a toolbar and its read mode is a rendered document, so it is composed through the slot rather than switched on with control. Two pieces do the work: the editor in the editor slot, and the document handed to read mode as markup.

<x-wirekit::inline-edit
    name="body"
    label="Release notes"
    :value="$post->body"
    :display-value="str($post->body)->toHtmlString()"
    wire:wirekit:inline-edit-confirmed="save($event.detail.value)"
>
    <x-slot:editor>
        <div
            wire:ignore
            x-on:keydown.escape.stop="cancel()"
            x-on:keydown.enter.meta.capture.prevent.stop="commit()"
            x-on:keydown.enter.ctrl.capture.prevent.stop="commit()"
        >
            <x-wirekit::editor
                x-ref="control"
                x-model="draft"
                :value="$post->body"
                aria-label="Release notes"
            />
        </div>
    </x-slot:editor>
</x-wirekit::inline-edit>

public function save(string $value): void
{
    // Read mode renders this as markup, so sanitize it before it is stored.
    $this->post->update(['body' => clean($value)]);

    $this->dispatch('wirekit:inline-edit-saved', name: 'body');
}

The slot's contract applies as written. x-ref="control" on the editor puts focus in its editing surface, x-model="draft" binds the document in both directions, and aria-label gives the editor the same words the visible label shows. clean() comes from mews/purifier, the sanitizer the editor page recommends. Beyond the contract, four things matter:

1. wire:ignore goes on the editor's mount node, and nowhere above it. The editor builds its editing surface in the browser, after the server has rendered the page. Without the marker, a Livewire round trip from anywhere else on the page puts that node back to what the server rendered, and the editing surface disappears along with the unsaved text in it. On the inline-edit itself the marker would also stop read mode from updating: the save reaches your component, and the reader keeps looking at the old document.
2. Read mode gets the document as markup. Passed to displayValue as an Htmlable, the document renders in the editor's own typography, so it keeps its look when the editor opens. A document with no text in it, such as the <p></p> an emptied editor produces, shows emptyText. Read mode renders the HTML as it is, which is why the save above sanitizes it.
3. Enter writes a paragraph, so the recipe binds the other two keys. Escape cancels and Cmd/Ctrl + Enter confirms. The confirm binding runs in the capture phase and stops there: Tiptap's starter kit binds the same shortcut to a line break, and bound any later, the break would land in the document just before it is sent.
4. Clicking elsewhere keeps the draft. The recipe binds no blur, so a paragraph of unsaved text survives a click somewhere else on the page, which is where it differs from the built-in controls. Confirm, cancel and Escape close the editor, and so does opening another one, as described in Several editors at once.

Error state

An error re-opens the editor, which is why the preview below is already in edit mode with nothing clicked. A rejected save arrives as a Livewire morph, and a morph replaces the open editor with read mode — so without this the reader is dropped back to the value they tried to change, holding an error about a field they can no longer see. The message is linked with aria-describedby, so it reaches the control rather than sitting beside it.

The error can come from either side: the error prop, or the validation bag under the field's name. Livewire reports a failed save() through the bag, so both are read.

<x-wirekit::inline-edit name="title" label="Project title" value="Quarterly report" context="Q3 planning" hint="Click the value to edit it in place." error="A project with that title already exists." />

Props

Slots

Accessibility

• The label renders in both modes and sits outside the part that toggles, so the field is never unlabeled while reading and the label does not jump into place on open
• The trigger is a real <button type="button"> with a 44×44 touch target
• An aria-label or aria-labelledby of yours names the built-in control, not the wrapper around it
• An inputmode, enterkeyhint, autocapitalize, spellcheck, maxlength, autocomplete or placeholder written on the tag goes to the built-in text, textarea or number control, a list to the text or number control, a min, max or step to the number control, and an autofocus goes to the trigger. A select takes none of them. A control of your own in the editor slot takes them on its own tag
• The value is a role="presentation" container, never a button — so its accessible name is not the value text
• aria-describedby composes the hint and error ids, and is never emitted empty
• Confirm and cancel use aria-disabled while saving, never disabled — a disabled button leaves the tab order mid-interaction, which loses the reader's place exactly while they wait to find out whether it worked
• With disabled, the pencil is a disabled button and leaves the tab order, as a disabled native field does: nothing is under way that the reader could lose their place in. The value is still read as text
• A second Enter during a save does not submit again
• The save outcome is announced through a polite live region
• While the editor is closed, its built-in field is disabled. The editor stays on the page, and a form checks every field it owns, shown or not: an empty required value, or a number off its step, would otherwise stop a form around the component from submitting with nothing on screen to say why

Keyboard Interaction

In the rich-text recipe Enter writes a paragraph, and the recipe binds Escape and Cmd/Ctrl + Enter itself.

In a textarea Enter writes a line, so it does not commit — Cmd/Ctrl + Enter does. That is also why the confirm and cancel buttons cannot be switched off for that control: without them and without knowing the shortcut, a reader would have no way to save at all, and the remaining exit discards.

Both Enter and Escape stop where they are handled. Without that, Escape inside a modal would close the modal as well as canceling the edit, and Enter inside a <form wire:submit> would submit the whole form instead of committing one field.

Pitfalls

• Do not bind wire:model to the draft. A two-way binding writes on every keystroke, which leaves nothing to confirm and nothing for cancel to restore. The draft is local until the reader commits.
• Do not infer success from the request finishing. Dispatch the saved event; a validation failure completes a request too.
• Add wire:key when rendering these in a loop, so a morph keeps each editor attached to its own row.
• Do not put wire:ignore on the inline-edit when composing rich text. It belongs on the editor's mount node inside the slot; on the root it stops read mode from showing what was saved. See Rich text.

Design Tokens

Usage & Conventions