primitives icon indicating copy to clipboard operation
primitives copied to clipboard

[RadioGroup] Unable to reset value in controlled mode

Open ckastbjerg opened this issue 3 years ago β€’ 8 comments
trafficstars

πŸ’ 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

ckastbjerg avatar Aug 02 '22 10:08 ckastbjerg

Similar to #1569

benoitgrelard avatar Aug 02 '22 10:08 benoitgrelard

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.

jjenzz avatar Aug 03 '22 10:08 jjenzz

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?

benoitgrelard avatar Aug 03 '22 20:08 benoitgrelard

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 πŸ™Œ

ckastbjerg avatar Aug 04 '22 07:08 ckastbjerg

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 RadioGroup by allowing null to 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.

jjenzz avatar Aug 04 '22 10:08 jjenzz

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?

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.

benoitgrelard avatar Aug 05 '22 08:08 benoitgrelard