Ability to auto resolve correct option and label for value prop #4829
Replies: 2 comments 2 replies
-
@ScottMRafferty Just so I am clear, is the request to allow options that are a String or Number type instead of an object or am I misinterpreting your request? Also, I didn't see anything mentioned about the props |
Beta Was this translation helpful? Give feedback.
-
I agree that it could be considered an anti-pattern but the behaviour is definitely clashing with other legacy select components including react-select-plus (the previous incarnation). Check out this sandbox. I've lowered React to 15.4 as the older select components rely on prop types etc. but for users with legacy projects looking to just pop in react-select as a replacement the fact it can't resolve raw values to labels is a problem especially if source of truth for value state is held outside of the select components i.e. controlled by a form manager etc. https://codesandbox.io/s/react-select-value-prop-behaviour-compared-nveoz I have two large projects that I upgraded from react-select-plus to react-select and this has proven to be the biggest headache as all the form schemas and controllers are based on holding values as raw values i.e. lang="en" or client_id = 345 and I instruct the select component to only output the value for the selected option back to the form controller in onChange. The form data values now have to be normalised in advance of passing into react-select (if async this is a pain) or normalised just before component instantiation (in the case of the options being available already). As I have 70+ JSON form schemas normalising all the necessary form value props to their option equivalents has required quite a lot of code rework. I can kind of get around some of this now using the SingleValue and MultiValue custom components. As far as type ahead async is concerned I agree with you that the raw value must be converted to the correct value object before passing in to react-select as there is no sensible way to derive the value object internally. In all other cases I believe the internal state value object can be derived from the available options and fallback to existing behaviour if not. I'm not saying that react-select should absolutely implement this behaviour (we have to move forward right?) but to my mind the component does deviate slightly from expected behaviour as far as it's own legacy component and other legacy components. It's definitely cost me at least 50-60 hours of work to put right in legacy projects and I know I was quite suprised by the behaviour when I first switched to react-select some time back. This may be due to the legacy components implementing bad patterns but a lot of legacy wrapper code will be written with that behaviour in mind. I can't imagine that I'm the only one to have come across this BUT... :-) In all react-select is an amazing component which is why I have perservered with this. I hope the sandbox example provides some further context as it is probably the most basic example of the behavioural difference from 2 previous components to react-select. You are also right that some of the reference terms (values, value objects, value object value) are confusing!!! Cheers. |
Beta Was this translation helpful? Give feedback.
-
Would it be possible to resolve the correct labels for options when the value options are not normalised i.e. pass in {value: 1, label: 1} or not objects (value or array of values) i.e. 1 and have react-select auto resolve the correct option based on the internal options available. I've experimented with the following 2 custom SingleValue and MultiValue components in a sandbox to do this:
It would be great to either have it automatically do this or at least have an autoResolveLabels prop to enable it.
I also notice that the components are not fired if the default value is a value and not an object. In the cases whereby I only have the values I can convert them to objects with the same value and label before I pass in but it would be great if I could just pass in a raw value or an array of raw values and react-select converted them internally to objects (with the label prop the same as the value prop) and then have the label autoresolve as above.
Some of the reasoning:
Just to be clear when I use the term normalise here I'm talking about taking a value ID and associating it with it's options object and ultimately normalising the ID to the label that the ID represents.
There is always the caveat that the label cannot be resolved if the options are aysnc fetched real time but as far as I can see in all other scenarios including async option prefetch the labels can be resolved if only a value or array of values are passed in. In the case of real time async existing behaviour would continue as is.
Hope this makes sense. If it seems like it might be useful I'm happy to make the changes and create a pull request but I thought it best to open up the discussion first.
Cheers.
Beta Was this translation helpful? Give feedback.
All reactions