Skip to content
shadcn.io

shadcn.io is not affiliated with official shadcn/ui

Quick Edit Command Menu Block for React

A support inbox's quick edit as a command menu shown open under a ticket's header: pick a field, edit it in the right control, see Before and After, and Enter saves into the record card.

Framework
UI library

Preview

Preview width

Installation

Part of Pro
Pro unlocks the code and one-line install of every Pro button and text effect, plus the MCP for your AI editor.
Have Pro already? Sign in to open it.Opens here as soon as you're Pro.

Overview

Change one field of a record without opening a form with this quick edit command menu for React with Base UI. It opens from the header of Ticket 2041 in Caselark, a support inbox, whose header holds an outline field with its ⌘ K cap, and the ticket is drawn under a soft scrim inside a hairline frame with a plus mark on each corner. The menu is the catalog Command over the record's five fields, each row with its current value and, once it has changed, what it was. Choosing a field turns the menu into the editor that fits it, in the same shell: a NativeSelect for Status, Owner and Priority, a date Input for Due and a text input for Title, with a Before and After line that shows what saving would change. Enter saves into the drawn record card behind the menu, which changes, and the menu goes back to the list so another field can follow; Escape goes back without saving and closes from the list. A date in the past or an empty title is refused in words. For preview the menu is drawn open in place when the page loads; the field, or Ctrl or ⌘ K while focus is in the block, opens the real command dialog with the same record, step and draft. For inboxes, trackers and any record with a handful of fields that change often.

FAQ

Why is the menu already open, and what do I keep?

So you can see it without a click. On load the menu is the Command drawn inline under a picture of the ticket, in a plain shell that is not modal, so nothing is trapped, hidden or focused and the page around the preview keeps working. The header's field opens the real command dialog, modal, with its focus trap, Escape and focus return, and the inline copy stays closed until a reload. Both show the same Palette and share the block's state, so the record you changed in the copy is the one the dialog opens with. In your app keep the dialog and drop the copy: the "in-place" state, the scrim with its shell and the Escape and blur effects.

How does each field get the right editor?

Each field in the typed data names its kind: select for a short list of choices, date for a day, text for free words. The edit step renders the control for that kind (a native select, a date input, a text input) with the field's label, and every one of them keeps its own accessible name and keyboard behaviour. A new field is one more entry in FIELDS, and a new kind is one more branch in Editor.

What do Before and After show?

Before is the record's current value and After is the draft as it would be saved (a title is trimmed, a date is written as a day). They read the same until you change something, and the foot says "No change yet" or "Changed". Saving a draft that equals the record changes nothing and says so. Once a field has changed, its row in the list shows what it was when the page loaded, so a row reads "Pending, was Open".

What happens with a bad value?

A past date or an empty title is refused in words, in the line under the editor and on the status line: "Pick 14 Oct 2026 or later." and "Give the ticket a title." Focus stays on the editor, and the draft is kept. The earliest day is a fixed constant in the block, not the clock, so the preview reads the same on every visit; in your app compare against the real day.

What stays local, and how do I wire it?

All of it. The ticket is typed state, nothing is saved or sent, and the record card is the only thing that changes. In your app give START_TICKET your record, send { field, value } to your API in save, and show its error in the same line a refusal uses.

Is it accessible from the keyboard?

Yes. Type to search the fields by name or by a word like assignee or deadline, the arrow keys move through them, Enter opens the editor, and Enter in the editor saves; Escape goes back, then closes. Focus moves to the editor when the step changes and back to the search field when it returns. Ctrl or ⌘ K opens the dialog while focus is inside the block, and only then. The rows are options of a cmdk listbox; the block turns off its own fuzzy filter and lists the rows itself.

  • Pro

    A help desk's reply library as a command menu shown open over a ticket: choosing a reply with slots turns the menu into a short form, a textarea previews the filled reply, and Enter inserts it.

  • Pro

    A notes editor's formatting menu shown open over a note: a real textarea with a sample sits above seven rows that format its selection or insert a block, and a preview and a mono line show the result.

  • Pro

    A localisation platform's string finder as a command menu shown open under a band of language chips with their coverage: keys with their text in the chosen language or the word Missing, a Missing only switch and a copy key button.

  • Pro

    A support console's view-as switcher as a command menu shown open under the avatar: You and Teammates with initials, role and queue size, a read-only banner with an Exit button, and a ticket list that shows only that person's queue.

  • Pro

    A to-do app's command menu shown open over the Today list: type a sentence to add a task with !1 to !3 setting its priority, tick tasks with Enter or Space, and filter Active, Done or All.

  • Pro

    Basic Command Menu

    Search everything

    A team workspace's home page with its command menu shown open: eleven pages in three groups, a shortcut on the five most used, matches marked, an empty state that says what to try and a foot with the key hints and a spoken count.