-
-
Couldn't load subscription status.
- Fork 43
fix: make select.web consistent
#57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
Added another fix to solve #58. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bryanmylee Thanks for another contribution.
For each `<Item>` component, keep track of its `value` to `label`
mapping on the `<Root>` component by passing a `MutableRefObject`
that stores the mapping from `<Root>` to `<Item>` via context.
On render, `<Item>` sets the label for its value. `<Root>` can then call
`onValueChange` with `labelForValueRef.current[val] ?? val`, allowing
feature parity with the native implementation.
This approach works perfectly. Since `Item` must be rendered before it
can be interacted with and emit events, this always ensures that
`labelForValueRef[val]` exists before `onStrValueChange` is called.
Furthermore, since the `value` and `defaultValue` prop requires `{
value: string, label: string }`, the initial render also does not have
any issues.
408e728 to
f771f8f
Compare
|
|
|
hi, any updates on this? |
|
Any updates on this? Why not make the other way around and change the Option to be a string instead of { value: string, label: string }? |
This solves #26 in making the
<Select>component consistent on web and native.For each
<Item>component, keep track of itsvaluetolabelmapping on the<Root>component by passing aMutableRefObjectthat stores the mapping from<Root>to<Item>via context.On render,
<Item>sets the label for its value.<Root>can then callonValueChangewithlabelForValueRef.current[val] ?? val, allowing feature parity with the native implementation.This approach works perfectly. Since
Itemmust be rendered before it can be interacted with and emit events, this always ensures thatlabelForValueRef[val]exists beforeonStrValueChangeis called. Furthermore, since thevalueanddefaultValueprop requires{ value: string, label: string }, the initial render also does not have any issues.