isRequired removed on Select?

petervdn · April 17, 2019, 2:06pm

From reading this it seems that Select has replaced single-select and multi-select. I haven’t used those, but the migration guide says that the isRequired prop has been removed. This leaves me wondering why that is and how i should handle a required select element in a form now.

Am i overlooking something? Why does the following not work?

<Field name="color" defaultValue="" isRequired>
  {({ fieldProps }) => (
    <Select
      {...fieldProps}
      options={[{ label: 'red', value: 'red' }, { label: 'blue', value: 'blue' }]}
    />
  )}
</Field>

evbo · July 11, 2021, 5:01pm

Sadly I think this is an issue with the underlying react-select library itself.

It would be great though if Atlassian provided a wrapper that performed the documented workaround for you. See original issue and workaround proposals here:

github.com/JedWatson/react-select

Input required and validation

opened 12:45AM - 12 Dec 20 UTC

ebonow

issue/needs-review

Creating this as a round up of existing open validation issues as of now. Hoping… to create some kind of proposed solution and seeking feedback before creating a PR though others are welcome to try as well so long as we all know the challenges and impact of solving for this. ### Use-case: As a developer working within in a form, I would like to apply native html validation to my react-select component. ### Duplicates: #2751 - Required attribute should be passed down... #3625 - Using Required attribute #1453 - Add validation support #4416 - Obtaining focus from the hidden input inside react-select #3140 - How to make react-select required in a form? #4450 - How to make reactselect get focus when required and empty ### Challenges #### 1. Single Input - Currently default behavior of react-select is to clear inputValue onChange event so validation on this input would by default always be missing a value, so applied validation to this input is already not-out-of-the-box easy to implement _Possible proposal: Introduce a visibly hidden text input which renders the selected value_ #### 2. Multi Input - What kind of validation rules should be applied? How would this be implemented? _Possible proposal: Introduce a visibly hidden text/select input which concatenates all of the values together and apply a `multiple` attribute_ #### 3. `isSearchable=false` - Currently a DummyInput is used for focusing the content to replicate the focus and blur functionality currently built-in _Possible proposal: Introduce a visibly hidden select input. Apply `multiple` attribute if it is a Multi Input._ #### 4. Visibly hidden input Notes: This visually hidden element cannot be readonly, disabled, have style `display: none`, and would likely have `tabindex="-1"` to ensure it does not interfere with focus order. Also currently (and curiously), the name prop is passed to a generated "FormField". My proposition would be to rewrite this formally as a component which also serves the benefit of decomposing Select.js. #### 5. Styling since anything other than a single searchable Select requires a visibly hidden input (type text or select or anything else a user suggests), then how would styling this element be possible? _Possible proposal:_ - Assuming above proposals, identify new/existing component to be used for validity - On mount of validator component, call `element.addEventListener('invalid', handleInvalid)` - Allow method `handleInvalid` to set new internal state `isInvalid` - Add internal state variable `isValid` and expose to other components (to style borders, colors, icons, etc) - Create new style component which would apply styles directly to the invalid element - Apply BEM modifier `--is-invalid` to this element to be specified in CSS (though `:invalid` is always available to the user as well) - On unmount of validator component, call `element.removeEventListener('invalid', handleInvalid)` #### 6. Breaking changes Would changing the behavior of the FormField be a breaking change? I suppose it is very possible depending on test suites and formalizing this as a component could have other impacts. Most everything seems additive especially since adding validation would likely be additive, however, due to the nature of this application, there exists the possibility that either `required` or `isRequired` could both already be pre-existing props so it is possible There is slight possibility of introducing conflicting css names. Introducing `InvalidInput` as a stylable component which is applied as `classNamePrefix__invalid-input` could help avoid these collisions. Perhaps greater likelihood is introducing css to apply to containers. It's possible `classNamePrefix__control--is-invalid` is already used, but I also believe it should be discouraged from applying internal naming conventions. Maybe, we consider adding another className to the control styled element called `classNamePrefix__validated-control` and styles can cascade from `classNamePrefix__validated-control--is-invalid` to avoid naming conflicts. That said, any feedback? If the changes are breaking then we would want to target version 4 rather than 3.2, but wanted to get community buy-in to better understand how to solve this issue given the flexibility and current functionality of react-select.