search

techniq / svelte-ux

Collection of Svelte components, actions, stores, and utilities to build highly interactive applications.
https://svelte-ux.techniq.dev/
MIT License
663 stars 33 forks source link

Fix error from keying on stringified objects #401

Closed myieye closed 1 week ago

myieye commented 4 weeks ago

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[bot] commented 4 weeks ago

🦋 Changeset detected

Latest commit: 3808df8d65f3951ee960a1cbf8c4e37df0ff7b60

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[bot] commented 4 weeks ago

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 commented 4 weeks ago

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).

image

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 https://github.com/techniq/svelte-ux/issues/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.

techniq commented 1 week ago

Hey @myieye, I went ahead and stacked #246 via #415 which caused a breaking change. I also just opened #425 that fixes the issue you were experience by leveraging JSON.stringify(option) to fix the object/key uniqueness. If you get a chance, could you review the small PR to make sure it resolves your issue. I'm going to close this PR for now. Thanks!