ref(cmdk) jsx powered cmdk

[JonasBa]

Refactor CMDK to a composable JSX approach.

Previously, our CMDK required knowing actions aot and use a hook registration process. We want to move to a fully JSX powered approach and eventually also make actions render to the DOM (this is currently not possible because virtualization is required and the listbox API requires us to specify the full list)

This change brings us half way to being able to power the CMDK UI by converting CMDK registration to JSX.

This enables some interesting patterns where the UI logic can be colocated with the UI as seen here.

The way that this works is through the following mechanisms:

• Collection context responsible for storing nodes and edges (essentially a recursive Context) that we use to maintain a parent<->child mapping.
• A store with a tree(root | undefined) method which will reconstruct the tree on-demand so that callers can have access to the most complete UI at all times

The slots API mentioned above this are used in CMDK as contextual priority slots that will appear as the first descendants of the CMDK action (similar to how priority int value used to work before). CMDK now has two slots, the first one is the global slot where global actions should be registered, the second is the page where broader page specific actions can be registered and the 3rd is the task slot, a slot that is contextual to what the user is doing (e.g. if they are editing a dashboard, saving or starring it might be a task they are currently interested).

[rbro112]

Since this is just the spec, I'd maybe say we just have claude update this file to just use the new JSX actions inline in the spec tests. Not a huge deal but should be easy enough then we're on the best practice moving forward

[rbro112]

Not touched here but should we type the output to be CommandPaletteAction | CommandPaletteAction[]? Still a tanstack newbie so that might be overkill, but I know we want the select transform to give us an action/array of actions so I don't see why we wouldn't require that unless that's unnecessary

[JonasBa]

Oh yes, this is an intermediary ttype that we can remove, I agree!

[rbro112]

At some point it might be good for us to pull these global staff actions out into their own component to keep this file simple (among potentially pulling out other global actions) but good for now

[rbro112]

Would it be worth touching on which slot a user can add to? really should only be task/page a dev could add, but probably worth calling out the difference/use case for each

[JonasBa]

Yes, my plan is to add a skill that will prompt the user to do this

[rbro112]

I don't see any "default" slot if not specified - might be missing in but which slot do CMDKActions that aren't registered within an explicit slot get added to? I'd assume page by default, but again don't see anything around that

[rbro112]

<CommandPaletteSlot.Outlet name="global">
  {p => (
    <div {...p} style={{display: 'contents'}}>
      {props.children}
    </div>
  )}
</CommandPaletteSlot.Outlet>

This may be it with the props.children rendering, but wondering if we should move into page?

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 006c238. Configure here.}

[cursor]

Duplicate CMDKAction import in documentation example

Low Severity

CMDKAction is imported twice on consecutive lines in the documentation code example. This is a copy-paste error that, while not causing a runtime issue, sets a bad example for developers copying the snippet.

 

^{Reviewed by Cursor Bugbot for commit 006c238. Configure here.}