-
Notifications
You must be signed in to change notification settings - Fork 47.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request to allow controlled checkboxes to remove checked when assigned null
#7530
Conversation
@@ -146,7 +146,7 @@ var ReactDOMInput = { | |||
|
|||
var defaultValue = props.defaultValue; | |||
inst._wrapperState = { | |||
initialChecked: props.checked != null ? props.checked : props.defaultChecked, | |||
initialChecked: props.checked !== undefined ? props.checked : props.defaultChecked, | |||
initialValue: props.value != null ? props.value : defaultValue, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If accepted, wouldn't this introduce a new inconsistency between controlled text inputs and checkboxes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True. Would it be unreasonable to extend this to text inputs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Has been discussed before and rejected. I don't think anyone feels super strongly about the current implementation, but changing it means breaking a lot of code.
Giving Given that there is a warning for |
Yeah, that should be a warning, but it appears to not be firing (https://jsfiddle.net/s4742gkk/). I'm going to close this out, track it as #7544 |
I know I'm getting back to this late, but bummer. I hope this isn't too much smoke blowing, but it doesn't seem like controlled/uncontrolled behavior should be regulated by the value types at all. It could be determined by the ownership, like if I'll have to dig into the history here. |
@nhunzaker I'd say it should be different components entirely. Doing it by property check isn't a good idea either, because then you can't easily have wrapper components passing along |
@syranide I think I follow. Do you mean that React should produce a new component instance when switching from controlled to uncontrolled? I believe that would certainly solve this case, and possibly eliminate some of the complexity around properly switching an input's "mode" as React attempts to recycle DOM inputs (do I have that right?).
True, but React's standard behavior gracefully accommodates it. If I set
Fair point; one I can't really argue against. |
Last time we discussed this everyone agreed that basically keying by controlled/uncontrolled internally is the right way to go (hence the warning, you should key it yourself). However, my point here is that IMHO
The difference is that This tolerance is also error-prone, because 3 values now correspond to the same visual input state (undefined, null and empty string). Which means that if you check for empty string it will fail because null/undefined. If you pass the value along then something else may fail to check for null/undefined or you may end up storing null/undefined in a database. Or it may be stringified somewhere else and become |
Thank you for the thorough response, though I apologize for taking you away Thank you for walking me through this! On Sat, Aug 27, 2016, 10:58 AM Andreas Svensson notifications@github.com
|
@nhunzaker Not at all, this is just my opinion on it and I find it interesting to discuss :) |
We hit a snag on a project where a piece of state backing a checkbox was set to
null
instead offalse
, and the checkbox checked state was not reflected in the UI.Steps to reproduce:
Expected: The checkbox is no longer checked
Actual: The checkbox is checked
Here's a recording of the behavior:
It looks like this happens because
null
returns a controlled input to the initial checked state (inst._wrapperState.initialChecked) it was mounted with:https://github.com/facebook/react/blob/master/src/renderers/dom/client/wrappers/ReactDOMInput.js#L78
To me, this is inconsistent with the behavior of other attributes. If given
null
, the attribute is removed. Additionally, ifinput.checked
is assignednull
directly, it becomes unchecked.This PR configures
ReactDOMInput
to respectnull
for controlled checkboxes. It will only ever fallback to initial mounted value onundefined
.If a change like this is impossible, could there be a warning or additional documentation along the lines of tips/controlled-input-null-value? I'm happy to follow up with an issue if so (I'll even write the docs, if given a formal stance).