Async search for option and multiOption

[noxify]

Do you think it would be possible to have a dynamic/async options generation based on the user input?

Example:

I have a task table which has a many-to-many relation to the assignee table.

Currently, I have to load all assignees and pass the result to the client component which renders the filter.
This works as expected, but open the filter and clicking the field ( in my case it's named as "Assigned to" ), I see a short delay until the list is rendered.

It would be cool if we could provide an option/method to support an "async search" for option and multiOption.

What do I mean with "async search"?

By default the options are an empty array, if the user starts typing, a function is called to calculate the options list ( in nextjs, we could use a server action to get the filtered list ) and the user sees just the relevant options.

I think filtering shouldn't be the problem, but tbh I currently have no idea how we could handle the selected values ( since we do not know them ).
Maybe having an additional method to fetch the selected values.

If you have any questions, feel free to ask :)

---

For the delay, I pushed my latest changes to my repo.

STRs:

git clone https://github.com/noxify/next-rsc-search
cd next-rsc-search
git checkout updates
pnpm i
pnpm db:generate
pnpm db:push
pnpm db:seed
pnpm dev

[linear[bot]]

UI-141 [Feature] Async search for `option` and `multiOption`

[kianbazza]

Async column options is definitely on the internal roadmap.

Questions for you:

• Are you seeing the delay in development or production (or both)?
• Roughly how many assignees?

[noxify]

Hey,

Currently I tested it only with the dev mode.

In the seeder I have configured 200 assignees. I assume the delay will increase if there are more (haven't tracked the time, maybe it's just a feeling and I'm the problem 😆)

[noxify]

In our internal project I have integrated https://shadcnui-expansions.typeart.cc/docs/multiple-selector into the react-querybuilder since I had similar problems.

Maybe this helps to get an inspiration how to implement it :)

[kianbazza]

I also notice a delay (~200-250ms) in dev mode. Could you check if the delay is present after next build && next start?

[noxify]

I also notice a delay (~200-250ms) in dev mode. Could you check if the delay is present after next build && next start?

Hey,

tested it quickly and it feels that it's instantly available. No noticable delay. Even with 1000 records in the list, it feels good. I can see a short delay, but it's ok for me ( and the usecase I have )

Update: I also clicked one element from the list, here you can see a "long delay". ( used `pnpm start )

Bildschirmaufnahme.2025-05-12.um.10.00.42.mov

[noxify]

Checked for existing issues in the cmdk package ( since we use it behind the scenes ) and found this one: dip/cmdk#335

maybe the mentioned repo ( using TanStack Virtual ) could help to solve it?
https://github.com/oaarnikoivu/shadcn-virtualized-combobox

---

Maybe this could be interesting, too? https://shadcn-multi-async-select.vercel.app/

[kianbazza]

Update: I also clicked one element from the list, here you can see a "long delay". ( used `pnpm start )

Okay, I think this may have to do with how we're handling grouped column options (introduced in v0.2). Let me see if I can optimize the computations for those.

For that specific column you're seeing a long delay for, are you using declared or inferred column options?

Checked for existing issues in the cmdk package ( since we use it behind the scenes ) and found this one: pacocoursey/cmdk#335

maybe the mentioned repo ( using TanStack Virtual ) could help to solve it? https://github.com/oaarnikoivu/shadcn-virtualized-combobox

Maybe this could be interesting, too? https://shadcn-multi-async-select.vercel.app/

I'm open to adding a virtualized version as an "add-on" installation from the registry. We can open the discussion to Discord members for feedback.

[noxify]

For that specific column you're seeing a long delay for, are you using declared or inferred column options?

I assumed that I have used the declared way, but based on my code and the docs, it seems I used inferred.
**Note: ** I assume this, based on the usage of transformOptionFn

I updated the filter definition from:

dtf
    .multiOption()
    .options([])
    .id("assignee")
    .accessor((row) => row.assignee)
    .transformOptionFn((value) => ({
      value: value.id,
      label: value.name,
      icon: undefined,
    }))
    .displayName("Assigned to")
    .build(),

to:

  dtf
    .multiOption()
    .id("assignee")
    .accessor((row) => row.assignee)
    .displayName("Assigned to")
    .build(),

but the result was the same ( after running next build and next start).

Ref:

• Current filter column config:
  • https://github.com/noxify/next-rsc-search/blob/updates/src/app/_config/simple-filter-columns.ts#L63-L68
• Fetching the assignees:
  • https://github.com/noxify/next-rsc-search/blob/updates/src/app/page.tsx#L13
  • https://github.com/noxify/next-rsc-search/blob/updates/src/app/_components/simple-filter.tsx#L45-L49

---

I'm open to adding a virtualized version as an "add-on" installation from the registry. We can open the discussion to Discord members for feedback.

makes sense to me, maybe converting the issue to a discussion?