CommandPalette
Search the command registry and run what you find.
import { CommandPalette } from '@textui/core';
<CommandPalette placeholder="Run a command" onClose={() => {}} />
Props
| Prop | Type | Default | |
| — | — | — | — |
| commands | CommandDefinition[] \| (() => CommandDefinition[]) | | Rows to search. Defaults to every enabled command in the palette slot. A function is re-read every render, which is what a list of switches needs: after one is flipped the row has to show its new state, and a snapshot taken when the palette opened cannot. |
| placeholder | string | | |
| onRun | (id: string, args?: Record<string, unknown>) => void | | Notified after a command runs. The palette runs it itself. |
| onClose | () => void | | |
| execute | boolean | true | Off makes this a picker: it reports the choice and runs nothing. |
| grouped | boolean | true | Group the list by category, with a rule between groups. |
| visibleRows | number | 8 | |
| width | number | 60 | |
| openAt | string | | Open already drilled into this command’s choices. For a caller that has decided which question is being asked and only wants the palette to ask it - a menu item for “Theme” should offer the themes, not the whole command list with “Theme” typed into the search box. |
Plus everything on BoxProps.
Role: dialog.
It searches the command registry, not a list you pass it. Anything
registered with the palette slot is in it, which means a feature becomes
reachable by registering a command and doing nothing else.
That is the whole argument for commands over handlers: the palette, the keybinding and the menu item cannot drift apart, because there is one implementation and three ways in.
commands overrides the registry for the rare screen that wants its own list;
execute={false} reports the choice through onRun instead of running it.