Replies: 6 comments 3 replies
-
Exploring a bit more, I found that using a custom Input with the prop
|
Beta Was this translation helpful? Give feedback.
-
Any progress on this? The proposed workaround doesn't seem to be working with Creatable (at least I didn't manage to make it work). |
Beta Was this translation helpful? Give feedback.
-
Any update on this? Trying to use the workaround with the |
Beta Was this translation helpful? Give feedback.
-
2023 and still with the problem. |
Beta Was this translation helpful? Give feedback.
-
2024 and its tragic we haven't been able to close this. |
Beta Was this translation helpful? Give feedback.
-
// const onFocus = () => value && selectRef.current.select.inputRef.select();
const onFocus = () => value && selectRef.current.inputRef.select(); Had to remove select from onFocus. Would be nice to have a prop for this instead. I wonder how much dev time has been wasted manually trying to get it working and adding all this extra useState. |
Beta Was this translation helpful? Give feedback.
-
Currently, the behavior of a react-select is such that when an option is chosen from the menu:
This has caused confusion for some users as the selected option label appears in the place of the input, but when the user tries to interact with it after its been selected, the cursor is instead positioned at the beginning of the text (since the input field is empty) and any character press will clear out the SingleValue instead of editing the input text as the user might expect of an input element.
I have created a codesandbox here demonstrating that it's still possible to create this behavior with the provided tools, though it requires a bit of brute force to override the inline opacity style passed to the input and could be much easier by addressing this line of code.
I think adding more complexity and code is something worth discussing and it's not without side effects. I think there are several questions related to this along with personal thoughts about answering some questions about the approch.
My answer would be yes. I believe this is a common enough use-case where a user may mis-click an option or simply want to change some input text. The default styling of the SingleValue and the Input are also similar enough that it can be misleading.
Not sure on this. I have considered several options:
My answer would be yes. While most users would only need to render the input, there is still the ability to set
controlShouldRenderValue
to false to to not break users who are using the rendered selected value elsewhere especially when using a formatOptionLabel function wherecontext === 'value'
bluee
, what should be the selected value?)My answer would be that any input text that does not match an option value reverts back to the label of the selected option (unless clearing the value).
Maybe it's one new prop, maybe several, maybe none, but at the end of the day, would love to know others thoughts.
Beta Was this translation helpful? Give feedback.
All reactions