Skip to content

fix: make select.web consistent#57

Open
bryanmylee wants to merge 3 commits into
roninoss:mainfrom
bryanmylee:fix-select-label-consistency
Open

fix: make select.web consistent#57
bryanmylee wants to merge 3 commits into
roninoss:mainfrom
bryanmylee:fix-select-label-consistency

Conversation

@bryanmylee

@bryanmylee bryanmylee commented Feb 1, 2025

Copy link
Copy Markdown
Contributor

This solves #26 in making the <Select> component consistent on web and native.

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.

@vercel

vercel Bot commented Feb 1, 2025

Copy link
Copy Markdown

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

Name Status Preview Comments Updated (UTC)
rn-primitives ✅ Ready (Inspect) Visit Preview 💬 Add feedback Feb 4, 2025 3:02pm

@bryanmylee

Copy link
Copy Markdown
Contributor Author

Added another fix to solve #58.

@mrzachnugent mrzachnugent left a comment

Copy link
Copy Markdown
Collaborator

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.

Comment thread packages/select/src/select.web.tsx Outdated
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.
@bryanmylee

Copy link
Copy Markdown
Contributor Author

closeOnPress is not handled on the web version of <Select>

@mehradotdev

Copy link
Copy Markdown

hi, any updates on this?

@vitorcamachoo

vitorcamachoo commented Sep 23, 2025

Copy link
Copy Markdown

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 }?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants