GeekyAnts / GeekyAnts/NativeBase
Radio.Group should allow un-selecting a radio button by changing `value` prop
- Dominant language
- TypeScript
- Stars
- 20.4k
- Forks
- 2.4k
- PR merge metrics
- No merged PRs in 30d
Description
### Description
The [RadioGroup's `value` prop](https://docs.nativebase.io/radio#h3-radio-group) implementation should change, such that if you had previously passed a string and now pass `undefined`, the radio input element will stop being selected.
### Problem Statement
Radio inputs normally do not allow the user to "un-select" an option; Their initial state shows e.g. 3 "unchecked" circles, and once the user has clicked one of them, they change to one "checked" and two "unchecked". Clicking the others will always check one and uncheck another, but re-clicking the same option will not change selection at all. This is standard behavior for radio buttons.
The implementation in NativeBase, relying on this assumption, seems to be care about the group's `value` prop only when it's defined (not `undefined`). Changing the prop from e.g. `value="red"` to `value="green"` will show the Red option unselected and the Green option selected. But, **Changing the prop from `value="red"` to `value={undefined}` will not change it at all**!
This problem means that certain forms cannot be "reset" properly.
#### Workarounds
Currently you can work around this by passing `key={selectedValue}` to the RadioGroup, because as the key changes the entire component is recreated. However, this solution is less performant and not ideal.
### Proposed Solution or API
I would like the RadioGroup's `value` prop implementation to change, such that if you had previously passed a string and now pass `undefined`, the radio input element will stop being selected.
### Alternatives
_No response_
### Additional Information
_No response_
Contributor guide
Research direction
Start at the RadioGroup value prop implementation and reproduce the transition from a defined string to undefined. Verify that changing the prop clears the selected radio input without requiring a new component key; the workaround described in the issue provides a comparison case.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- react, react-native, typescript
- Domain
- frontend, mobile
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 55/100