react-component / react-component/select
`<Select>` component `<form>` compatability
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 938
- Forks
- 482
- Avg merge
- 15h 8m
- Merged PRs (30d)
- 2
Description
Description
Currently <Select> component is not fully <form> compatible, which means when you submit a <Form> or <form> the data from the <Select> is not included in the form submission.
How to Reproduce Bug
Submit a form which contain's <Select> (see video below or see codesandbox here)
- observe that form submission does not update the URL
- observe that no data is being sent to the backend
Motivation For Changes
1. HTML <form> compatibility
- Being
<form>compliant means that people have the additional option of using Ant's<Select>in a similar way to using a standard<select>without losing the great UX/UI that<Select>offers (for example using<Select showSearch>is awesome!)
2. Many of Ant design's existing form-related components are already <form> compliant
<Input>,<InputNumber>and<Mentions>are already<form>compliant- codesandbox testing
<form>compliance of components above https://codesandbox.io/s/draft1-testing-ant-form-compatability-forked-z35rhu?file=/app/routes/examples/checkbox-component.tsx
- Removes the need for a user of Ant Design to manually add hidden input fields . This is the same issue Tailwind Headless UI had but solved in this pull request
Proposition of Changes
The proposed changes below are backwards compatible:
-
allow user to pass
nameprop to<Select>to achieve feature compliance with regular<select>which does allownameprop (Ex:<select name="vehicle">).

-
When a user passes
nameprop to<Select>generate a hidden input (<input type="hidden" name={selectProps.name}>) and when the user selects the value from the list, addvalueattribute to the hidden input and set it to the selected value (<input type="hidden" name={selectProps.name} value={selected_value}>. Inspiration for this implementation comes from Tailwind's Headless UI react library (Github Pull Request)
For single item selection (fake code for demonstrative purpose)
<Select showSearch style={{ width: 300 }} name="job_title">
<Select.Option value="engineer">engineer</Select.Option>
<Select.Option value="teacher">teacher</Select.Option>
// This hidden input would get generated from <Select> when a `name` prop is provided
// <input type="hidden" name={select.props.name} value={the_selected_value}>
</Select>
For multi selection (fake code for demonstrative purpose) mode=tags | multiple
<Select showSearch style={{ width: 300 }} name="job_title">
<Select.Option value="engineer">engineer</Select.Option>
<Select.Option value="teacher">teacher</Select.Option>
// Any time a new item is selected a new hidden input is generated from <Select> when a `name` prop is provided
// <input type="hidden" name={select.props.name} value={the_selected_value}>
// <input type="hidden" name={select.props.name} value={the_selected_value}>
</Select>
Summary
To solve this, <Select> needs name prop support & it needs to generate a hidden <input> element for the selected value
References
Documentation for <form> comptability
<form>compatibility example Github Pull request for tailwind React UI library + example tests- documentation for `
Related Issues
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the implementation and reproduce the issue using the linked CodeSandbox form example. Review the related react-component/select issues 790 and 791 for context on form behavior. Done means a named contributes its selected value, including multiple selections, to native form submission without changing existing usage.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- react, typescript
- Domain
- frontend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 48/100