useSwitch does not expose validation API

[vbudovski]

Provide a general summary of the feature here

Unlike most other hooks, the useSwitch hook does not provide isInvalid and validationErrors properties.

🤔 Expected Behavior?

useSwitch exposes the standard validation API.

😯 Current Behavior

useSwitch does not expose the standard validation API.

💁 Possible Solution

useSwitch exposes the standard validation API.

🔦 Context

It makes usage in forms difficult as it does not behave like other inputs.

💻 Examples

const { inputProps, isInvalid, validationErrors } = useSwitch(props, state, ref as RefObject<HTMLInputElement>);

🧢 Your Company/Team

No response

🕷 Tracking Issue

No response

[devongovett]

We couldn't think of a usecase for a switch that could be in an invalid state. Do you have one?

[vbudovski]

It could be used in place of a checkbox which does have this validation function. You might want to display an error when the switch is on/off depending on some condition. I think the use case should really be left up to the implementer.

[devongovett]

For checkbox the usecase is forcing the user to agree to some terms of service or something. But that wouldn't be an appropriate use of a switch which represents an on/off state instead of selected/checked. I'm having a hard time imagining a case where something being on or off would be invalid. Do you have a concrete use case?

[vbudovski]

Consider the situation where this switch being toggled fires off an API request. For whatever reason it fails (unexpected error or business logic). It would be nice to be able to communicate this issue to the user in context and reset the toggle state to reflect reality. You could maybe add an error message to the form itself, but it would not always be appropriate.

[binaryartifex]

i was about to post this issue. to play devils advocate here, imagine you've set up some kind of marketing campaign that runs over a certain period, the switch essentially enables your campaign to run, however server side validation reveals that the campaign overlaps a black-out period (work with me here). the switch being used as some kind off 'on/off' status semantic to a resource isn't unheard of and it helps with form component consistency. imo all form components should have at least an opt-in capacity for descriptions and error messages. let the library consumer decide if they want to take advantage of it or not.