JedWatson / JedWatson/react-select

Input required and validation

Open
#4,327 15 comments 12 reactions 1 assignee View on GitHub

@ebonow is already working on this.

Since Dec 12, 2020.

issue/needs-review
Dominant language
TypeScript
Stars
28k
Forks
4.1k
PR merge metrics
No merged PRs in 30d

Description

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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.