When the [FormControl] component is rendered with the disabled={true} prop, the children [Checkbox], [Radio], and [Switch] components remains enabled
All the children components of [FormControl] that use [FormControlContext] should be disabled if the [FormControl] components is disabled
This sandbox demonstrates the issue that appeared from v4.6.1 due to this pull request.
This sandbox clearly shows that everything was working correctly in v4.6.0
The [SwitchBase] component checks whether it has own disabled prop. If it doesn't have it, the disabled from [FormControlContext] is used (please see source code)
The issue is that the [Checkbox], [Radio], and [Switch] components were configured to use the disabled prop set to false by default (please see checkbox, radio, and switch changes).
Therefore, the [SwitchBase] component never receives the disabled={undefined} prop, which leads to non-usage of the disabled value from [FormControlContext]
| Tech | Version |
| ----------- | ------- |
| Material-UI | v4.8.3 |
| React | v16.12.0 |
Speaking of this issue, I can see three options I could fix this issue
disabled prop let disabled = muiFormControl && muiFormControl.disabled || disabledProp;
disabled prop back to undefined in the [Checkbox], [Radio], and [Switch] components, but I'm good with disabled = false by defaultdisabled prop to use and then passes it directly to the control component. What I'm getting at is that we might get rid of the muiFormControl.disabled check inside the [SwitchBase]Before I get started working on this issue, I really wanna hear your guys opinion
This change was intentional in support of the Framer components that require a default (albeit with this unintended consequence).
Me too, but we do document it as an option. @oliviertassinari what is the intended use-case for unlabelled selection controls?
InputBase, FormControlLabel, Radio, Checkbox, Switch, and SwitchBase should use the same approach. Hence, revert the default prop of the Checkbox, Radio, and Switch (option 1). However, we could consider a different approach to v5.IIRC, it should be possible to add it to each component's propValues in framerConfig.js. Adding it to the component directly was intended to fix the problem "at source", while also allowing the default to be documented in the prop docs; but clearly it backfired in this instance!
If you don't mind, I'll take it over
Most helpful comment
IIRC, it should be possible to add it to each component's
propValuesin framerConfig.js. Adding it to the component directly was intended to fix the problem "at source", while also allowing the default to be documented in the prop docs; but clearly it backfired in this instance!