fix: select component to handle empty string values for keyboard

[max-got]

Closes #977

Fixed empty value keyboard selection for SelectComponent.
The diff is very large, but just because i've added an empty value option in the items array inpackages/tests/src/tests/select/select.test.ts file.

Added a few tests as well + enhanced the Components for the Docs to showcase disabled options and an option with an empty ("") value. Tho that can be further enhanced, to showcase the possibilities even further.

I have added test helpers in packages/tests/src/tests/helpers/select.ts because i needed a way to generate a valid testId for the select components. Because there are 3 Components + the test file, it felt right to abstract them away in a helper. I dont't know if that this is your desired approach. Let me know if there is something wrong.

[changeset-bot]

🦋 Changeset detected

Latest commit: 221b20e

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
bits-ui	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

built with Refined Cloudflare Pages Action

⚡ Cloudflare Pages Deployment

Name	Status	Preview	Last Commit
bits-ui	✅ Ready (View Log)	Visit Preview	221b20e

[huntabyte]

Hey @max-got thanks a ton for digging into this.

I think it's a bad practice to have an empty string as a value of one of the options as it makes it indistinguishable from an item not being selected at all. When you open the select, it has a value selected, but the placeholder is shown, and the data-placeholder styles are applied.

I'm fine with this being added, but we won't be demonstrating it in the main demo or showing any examples of it. It will be more of a case of if you really want to do this, it's possible, but there are more explicit ways it should probably be done (i.e. using allowDeselect) and not having a value selected at all. If none is truly an explicit "theme" the user can select, it should be tied to a value that isn't an empty string (IMO of course).

[max-got]

Totally fair point. I read up a bit on value="" and unfortunately didn't get a definitive answer as to which is better. Especially in relation to accessibility concerns. With the change I just wanted to bring the Select component closer to the native <select> element. The ARIA (APG) Select-Only Combobox Example also sets an initial "option" which is value-less. The difference is that this example uses the first option as placeholder tho. So i'am agreeing with:

When you open the select, it has a value selected, but the placeholder is shown, and the data-placeholder styles are applied.

And to:

[...] but we won't be demonstrating it in the main demo or showing any examples of it [...] 👍

Maybe we can think about it a bit? I will revert the demo example

For example the following is closer to the <select>, which imo some consumer prefer.

const themes = [
+		{ value: "", label: "Select a theme" },
		{ value: "light-monochrome", label: "Light Monochrome" },
		{ value: "dark-green", label: "Dark Green" },
		//...
	];

	let value = $state<string>("");
	const selectedLabel = $derived(
- 		value ? themes.find((theme) => theme.value === value)?.label : "Select a Theme"
+		value ? themes.find((theme) => theme.value === value)?.label : themes[0].label
	);

but the bottom line is, i don't know either 🤷‍♂️

[huntabyte]

Yeah, I see their example does do that... interesting 🤔

For now, let's leave it off our main example here, but I'll take it under consideration as the "default" experience.

If you think it would be beneficial, we could add another example towards the bottom in its own docs section showcasing that capability!

[max-got]

I don't think there is a need for extra docs/section. There will be issues/questions if something is off

[huntabyte]

Thank you!