feat(cmdk): New CmdK action pattern and support Async actions

[rbro112]

Adds a new action pattern for registering CmdK actions:

 // Static or simple async actions
<CmdKAction actions=[{...}] />
// Actions that require a managed async action
<CmdKAction
  queryOptions={() => {
    const baseOptions = apiOptions.as<ResponseType[]>()(path, {
      path: {...},
      query: {...},
      staleTime: 30_000,
    });
    return {
      ...baseOptions,
      select: raw => baseOptions.select(raw).map((target): CommandPaletteAction => ({
        to: target.to,
        display: {
          label: target.label,
          details: target.description,
          icon: <IconIssues />,
        },
      })
    };
  })}
  />

These are tracked centrally using a set of promises and a loading state replaces the search icon when any promise is still in flight. As promises resolve, they're removed from the set.

Additionally, I provide a grouping mechanism with CmdKActionProvider (not sold on this):

<CmdKActionProvider groupingKey="snapshots">
  <CmdKAction actions=[{ ...download snapshot images action }] />
  ...

  <SnapshotsUI ... />
</CmdKActionProvider>

This allows for dynamically generating scoped actions as part of specific contextual locations. This example above would generate a "snapshots" group of actions within the palette.

Adds two simple global actions leveraging this async pattern to globalActions.tsx - the existing DSN lookup action using our new pattern and a docs search action to search Sentry dev docs.

[rbro112]

• feat(cmdk): New CmdK action pattern and support Async actions #112015 👈 (View in Graphite)
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

[JonasBa]

Does this need to be a function or can we simplify to CommandPaletteAction[] | Promise<CommandPaletteAction[]?

[rbro112]

Had it as a function in case users wanted to make it more dynamic, but the promise itself could handle that. Will update

[rbro112]

I was getting confused between these actions and other command palette actions, so I think this rename is a small but important change

[rbro112]

Not sold on this pattern in the current impl. CommonCommandPaletteAction is limited to a set of possible groupingKey strings ('search-result' | 'navigate' | 'add' | 'help').

My intention here is to be able to group actions by a "sub group" - basically any dynamic string. As a dev on size analysis and snapshots, the idea is to group our contextual actions into "Size Analysis" and "Snapshots" groups which would show in our palette as subheadings.

But this would require a bit of a refactor here to add a group?: string prop on CommonCommandPaletteAction and then render those titles/groups.

To start this seems fine with small scope and usage of this, but could explode if we have tons of teams adding groups. Also could get strange if we have nested groups or actions get grouped when actions are registered in potentially unexpected locations. Generally I almost lean to removing this entirely and potentially implementing in a future iteration once we have a better idea of usage