Fix error from keying on stringified objects

[myieye]

As the added example demonstrates, if you use objects in a SelectField, it causes an error, because the keyed each has duplicate keys (i.e. [Object object]). Perhaps I should just remove the -${optionValue(option)} part? In theory that would be a slightly more breaking change, but it would probably be fine.

There's an inconsistency in the select-fields in that the MultiSelect value field is of type string[] | number[] 🤷 while SelectField value is of type any. Is that intentional?

[changeset-bot]

🦋 Changeset detected

Latest commit: 3808df8

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

This PR includes changesets to release 1 package

Name	Type
svelte-ux	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

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
svelte-ux	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jun 20, 2024 0:51am

[techniq]

As the added example demonstrates, if you use objects in a SelectField, it causes an error, because the keyed each has duplicate keys (i.e. [Object object]).

Perhaps I should just remove the -${optionValue(option)} part? In theory that would be a slightly more breaking change, but it would probably be fine.

There is a use case where you can have the same value in multiple groups (albeit rare). The selected value in the menu will also show as the first one (since it doesn't know which group was selected from), but this does require the fully qualified key (group/value).

Instead of including the label (since the values will be [Object object]), what if instead we JSON.stringify(...) the value. This will technically be slower, but unlikely perceivable.

There's an inconsistency in the select-fields in that the MultiSelect value field is of type string[] | number[] 🤷 while SelectField value is of type any. Is that intentional?

This is not intentionally. There is a lot of alignment between the various select fields that need to be done (see #246). While a breaking change, I think it's worth getting rid of optionText()/optionValue() and labelProps/valueProp and require the user to pre-process the options into the standard { label: string, value: T } structure, which will simplifying each implementation. Align values and leveraging generics more is another big win. These kind of changes are one of the reasons I'm keeping Svelte UX pre-1.0 so they can be made within running up the major version numbers.