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.

#Keyboard

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.

#Where focus goes

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

#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"
    />

    <x-wirekit::inline-edit
        name="summary"
        label="Summary (textarea)"
        control="textarea"
        value="A short description that wraps onto more than one line."
    />

    <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.
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.

#Props

#Accessibility

• The label renders in both modes and sits outside the part that toggles, so the field is never unlabelled 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
• 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
• A second Enter during a save does not submit again
• The save outcome is announced through a polite live region

#Keyboard Interaction

#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.

#Design Tokens

#Usage & Conventions