Add searchable select

[DTCurrie]

Adds a searchable version of the select using an input and a custom menu:

Also includes a bundle of small fixes and adjustments that came up during review/testing.

[mcous]

Initial thoughts

[mcous]

I see how the store-based solution for unique IDs works, but I don't love how it requires to add an extra context provider to use the some components in the library. Given that this implementation is not SSR stable, would it be better to simply go with nanoid/non-secure and forgo adding in a required context?

[DTCurrie]

I see how the store-based solution for unique IDs works, but I don't love how it requires to add an extra context provider to use the some components in the library. Given that this implementation is not SSR stable, would it be better to simply go with nanoid/non-secure and forgo adding in a required context?

We could also just have it track the count internally without a store, but then we will need to require it be imported via a context="module" script which could add a level confusion.

I am cool with just using nanoid or just a string generator function in JS if we aren't super worried about it.

[ethanlook]

nit: consider using userEvent for this testing to simulate interactions

[DTCurrie]

I noticed we hadn't migrated elsewhere and @testing-library/svelte does not include userEvent. If we want to move to that, I would rather have a follow-up ticket to apply it in all of our tests instead of having a mix of solutions.

[ethanlook]

Why are these necessary given L59?

[DTCurrie]

Because we always set them as present, it makes the typing a lot more clear in the IDE especially since we are constantly checking against 0 and -1. Plus we always want to enforce they are present and arrays:

[ethanlook]

What is the intention of an undefined event value? If undefined is meant to mean "empty", could this be typed as null? Or maybe an explicitly typed object would be most clear to the consumer?

[DTCurrie]

It signals the event does not include any data, essentially a () => void handler. We just want to signal when the button has been clicked, we make no other assumptions about it.

[ethanlook]

In the cases that I've wanted this, I've explicitly typed the return as Record<string, never> to signal to the consumer the lack of associated detail

[DTCurrie]

I read through a bunch on this and landed on this PR where the feature was added, specifically this comment: sveltejs/svelte#7224 (comment)

Also with this, we signal to the user the detail is undefined:

If I use Record<string, never> this is what we show the user, which is way less clear IMO:

[DTCurrie]

Though looking at the migration docs for v4 it seems null is preferred so we can swap to that. Generally I prefer undefined but I don't mind sticking to their recommendation: https://svelte.dev/docs/v4-migration-guide#stricter-types-for-svelte-functions

[mcous]

LGTM, agree with Ethan's comments