[Question] - Is it possible to just pass a id to value rather than label and id ?
See original GitHub issueI would expect this to work like this:
<select value={this.state.valueId} onChange={this.handleChange}>
<option value="some_id_name">Grapefruit</option>
</select>
where as im finding it needs to be passed in value={{label: this.state.label, value: this.state.valueId}}
This is highly annoying as all my results come from a database of just IDs and i use a reference list of options to select them
Any work arounds ?
im currently having to search for the correct label against my reference data which is more loops than id rather be doing.
Thanks Luke
Issue Analytics
- State:
- Created 5 years ago
- Reactions:16
- Comments:16
Top Results From Across the Web
How to pass the id attribute instead of the value - Stack Overflow
One possible option is to use the input event and set the value manually. $('#to-selected').on('input', ...
Read more >Using label elements to associate text labels with form controls
The id attribute may have the same value as the name attribute, but both must be provided, and the id must be unique...
Read more ><input type="email"> - HTML: HyperText Markup Language
The <input> element's value attribute contains a string which is automatically validated as conforming to email syntax. More specifically, there ...
Read more >ID attribute values must be unique | Axe Rules | Deque Systems
The ID attribute uniquely identifies elements on a page. It does not make sense to duplicate an ID. Duplicate ID's can break the...
Read more >Passing Information via Query Strings - Qualtrics
The second query string begins with an ampersand (&) instead of a question mark (?). This is because URLs can only support one...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I totally agree with @designalchemy
Version 1.x had the correct implementation. The value attribute in select options are always unique. Why do we have to provide an object for the value prop 😕
It means that I have to do a filter operation like Luke has mentioned above or custom workarounds for Select inputs to place nice with my other form components. This adds unnecessary complexity.
Why was this change made?
Totally understand the decision to go in this direction, and it’s not too tough to refactor my old components to work with the new API, but this should probably be called out more clearly in both the intro documentation as well as the upgrade documentation. It might also be nice to use a different prop name than
value
in order to make it clear that this component isn’t a drop-in replacement for a normal select.I can take a stab at writing a bit of documentation if that would be welcome.