primitives
primitives copied to clipboard
[RadioGroup] Unable to reset value in controlled mode
π Note, I originally started a discussion around which where it was suggested that this might be a bug.
Bug report
Current Behavior
When using the RadioGroup in controlled mode, it doesn't seem possible to reset it (so that none of the items selected) without violating type rules. The component only allows a string or undefined as the value. Passing null seems to correctly reset the radio group, but isn't an allowed value.
Expected behavior
I'd expect that it's possible to reset the value of the RadioGroup somehow. Either by passing undefined or allowing null.
Reproducible example
https://codesandbox.io/s/heuristic-brook-x77cul?file=/App.js
Suggested solution
If there are no downsides, it seems that the type here could simply be updated to allow null for the value prop.
Your environment
| Software | Name(s) | Version |
|---|---|---|
| Radix Package(s) | @radix-ui/react-radio-group | 1.0.0 |
Similar to #1569
to my knowledge, once you assign a value to a radio group it cannot be removed.
the WAI ARIA docs are pretty clear that interacting with a checked radio should do nothing.
Note: The state where a radio is not checked only occurs on page load.
That's a good point, i did wonder as well as I thought it's not a thing with the native ones either. @ckastbjerg do you have an actual use-case for this that wouldn't be just a full form reset?
Some good points. Might very well be that the API is as it should be.
the WAI ARIA docs are pretty clear that interacting with a checked radio should do nothing.
Just to be clear, I'm not arguing that interacting with a checked radio should make it unchecked. So totally agree with this π
Note: The state where a radio is not checked only occurs on page load.
Interesting. If this is in fact the way the web should work, then we may just need to adjust our UI instead.
@ckastbjerg do you have an actual use-case for this that wouldn't be just a full form reset?
You can see the specific bug (issue) I'm working on a fix for here:
https://user-images.githubusercontent.com/9532512/182785711-689a8cca-aca5-4f2b-88c1-3df0f76ac0cc.mp4
The thing is that we're currently using the RadioGroup as a stand-alone component (not within a form) in this case. It's used in combination with a component we use for filtering, which is not form based. I guess it might be an anti pattern to use it outside a form in the first place?
But say I did change it to be within a form element and did a full form reset (something like this I guess). From an accessibility (and UX) standpoint, that doesn't seem any different than resetting the Radix RadioGroup by allowing null to me. That would also violate the rule stating that:
The state where a radio is not checked only occurs on page load.
Or am I missing something?
If you still think that the API is as it should be based on these details, a simple solution for my specific issue would be to add an additional (default) option like "All". And otherwise see if I can wrap it in a form.
In any case, thanks a lot for the input π
But say I did change it to be within a form element and did a full form reset (something like this I guess).
hmm, yeah that's an interesting example.
that doesn't seem any different than resetting the Radix
RadioGroupby allowingnullto me
in this case i think i agree. perhaps the WAI ARIA docs are trying to express that interacting with the radios themselves should not clear their value and so "resetting" from an external interaction would be fine but i'm not sure how radix could enforce that via controlled api.
perhaps easier to just allow it as i am unable to find any supporting material on why they say radios should only be unchecked on page load.
But say I did change it to be within a
formelement and did a full form reset (something like this I guess). From an accessibility (and UX) standpoint, that doesn't seem any different than resetting the RadixRadioGroupby allowingnullto me. That would also violate the rule stating that:The state where a radio is not checked only occurs on page load.
Or am I missing something?
Yeah exactly that's why I asked about the reset form case, because that's definitely a thing (and something we don't currently do, which is the issue I linked to).
β¦and so "resetting" from an external interaction would be fine but i'm not sure how radix could enforce that via controlled api.
Yeah that's the difficult part with undefined because of the controlled/uncontrolled nature. We detect as "controlled" if there's a value if the prop is defined. It might be that null is the only way forward. I haven't looked at the problem yet, but I think it's a general issue we have with all those form components, given how our useControllableState works and the controlled/uncontrolled detection.
At the very least, I think we need to make sure all form components reset their state when a form reset occurs.
I'll keep the issue opened then @ckastbjerg, thanks for the further responses.