shadcn.io is not affiliated with official shadcn/ui
REST Client Requests Command Menu Block for Ark UI
An API client's command menu shown open over a drawn client window: four saved requests and six from the history, a method switch with counts, and an Enter that re-sends one with a 900 ms Sending state and a typed status.
Installation
Overview
Replay a request without leaving the keyboard with this REST client command menu for React with Ark UI. It opens from the requests page in Dispatchbox, an API client, whose header holds an outline field with its ⌘ K cap, and the client is drawn under a soft scrim inside a hairline frame with a plus mark on each corner. The menu is the catalog Command with a ToggleGroup of methods above the field (All, GET, POST, PUT, DELETE, with a count each): saved requests first, then the history, each row with its method as a word in mono, its path, the status of its last send and a fixed time. Enter re-sends the highlighted request: its row shows a spinner and "Sending…" and then a typed status, and the drawn client's response header follows. 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 requests, filter and query. For API clients, test consoles and any tool where the next call is usually one you made before.
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 over a picture of an API client, 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 a re-send or a filter in the copy is in the dialog. 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.
What does Enter do?
It re-sends the highlighted request. For 900 ms the row shows a spinner and "Sending…", the status line says nothing leaves the page, and then the row takes the status and time that request is typed to get, which can differ from the last one: a delete that returned 204 now returns 404, a failed payment now returns 201. Only one send runs at a time, and Enter during one says to wait.
How does the method switch combine with the search?
The switch keeps one method (or All) and the search narrows within it by method, path, status or group, so GET plus "invoices" shows the invoice reads. Each chip shows how many requests use that method, and the foot counts the rows shown. The chips scroll sideways on a phone.
How is a status shown without colour?
Each status is a word with its code ("404 Not Found") next to a glyph, a tick for a 2xx and a warning for anything else, and the time and duration sit under it on screens wide enough. Nothing relies on a green or a red.
What stays local, and how do I wire it?
All of it. The ten requests, their statuses and what the next send returns are constants, and no request is made. In your app call fetch for the chosen request in pick, keep the row in its Sending state until it settles, and write the real status, time and duration back into items in place of the typed next.
Is it accessible from the keyboard?
Yes. Type to search, Tab reaches the method switch, the arrow keys move through the rows, and Enter re-sends. Escape closes the menu with focus on the field, and Ctrl or ⌘ K opens the dialog while focus is inside the block, and only then. The rows are options of a combobox and the first is highlighted when it opens.