Can't update 'checked' attribute

[jdelafon]

Consider this input:

<input
    type='radio'
    value='2'
    checked={this.state.value === '1'}
    onChange={this.onChange}
/>

onChange: function (e) {
    this.setState({value: e.target.value});
}

If the first time the component is rendered, this.state.value === '1', then this input will remain checked forever in the DOM, even if it appears unchecked visually. For instance this can happen with

getInitialState = function() {
    return {value: '1'};
}

I am using React 0.14.7.

[zpao]

I can't reproduce this (or maybe am misunderstanding what you're saying). https://jsfiddle.net/rkc64ybp/ is showing that the node is unchecked in the DOM. You might run into issues if you use e.preventDefault() but I don't see that in your code here.

[aweary]

@zpao I believe he means that, even after unchecking it, the <input> element still has the checked attribute if you inspect it in devtools. That seems to be the case on my end, at least.

Chrome 49.0.2623.87 (64-bit) FWIW.

[jdelafon]

Yes, that is what I meant, sorry if it wasn't clear. I tried Firefox and Chrome.
It is not really a problem for user experience, but it is for functional testing (although a workaround is to set className={value === 1 ? 'checked' : ''} and use the class as a selector).

A screenshot of the fiddle with the debugger showing checked="" while the button is unchecked:
http://postimg.org/image/9jjk26tjx/

The strange thing is that indeed e.target.checked is false. So can it be a devtools bug in both Firefox and Chrome ?

The contrary effect is also true: I have initially unchecked inputs that never get the checked attribute when clicked, although they get selected visually, and e.target.checked returns true.

[zpao]

Ah, I see. The attribute is set but the property isn't. That will be solved in v15 where we will remove the attribute instead of just setting the property to false. See https://jsfiddle.net/rkc64ybp/1/ (same code, just with hasAttribute calls and upgraded to 15, I saw the issue with 0.14)

[aweary]

@zpao should React add the checked attribute to the <input> element when it's checked in v0.15? With that JSFiddle it just looks like it doesn't add the checked attribute at all. Or does it just handled checked state internally and not set the checked attribute at all?

[zpao]

That's a good question… @syranide - was there any discussion about that?

[syranide]

@zpao There was/is a separate discussion about inputs and value somewhere else (cc @spicyj). I'm not sure where it ended up but it was about going away from the native behavior seen here to actively update the attribute in the DOM (EDIT: perhaps not intentionally, but that was the result). However, it should be noted that the behavior seen here is expected behavior, you get this behavior with native checkboxes as well; the checked property is updated, the attribute is not as it reflects the initial state.

[jdelafon]

Ah, I did not know that it was the native behavior... Then it is not a React issue at all, and I don't think React should try to have a different behavior. That sucks though, it means for instance that one should never use the input:checked CSS selector anyway to style the currently selected element, and a className='checked' is the only way Selenium can find it.

[syranide]

@muraveill I would assume input:checked works and that's specifically why it was added, but not input[checked] (tests for attribute).

[sophiebits]

Once again, I'll repeat that it does not make sense to talk about the native behavior here. That is, HTML does not have a concept of going from

<input type="checkbox">

to

<input type="checkbox" checked>

We created this concept. In HTML, you can do a property assignment (.value =), attribute assignment (.setAttribute), or you can blow away the entire thing and replace the whole node with .innerHTML. You can also have the user click it.

We can decide for any of these to be the behavior that React matches. None of them is the objectively correct "native behavior" so it's misleading to talk as if that were the case.

It seems like setting the attribute is least confusing for people in most cases (so that both [checked] and :checked would work), but it's still not clear whether that's best, especially with forms.

[syranide]

Once again, I'll repeat that it does not make sense to talk about the native behavior here. That is, HTML does not have a concept of going from

We can decide for any of these to be the behavior that React matches. None of them is the objectively correct "native behavior" so it's misleading to talk as if that were the case.

I still don't buy it, the specification explicitly states that the attribute reflects the initial value and the property reflects the current value. So if you check it without any additional scripting applied, this is the behavior you get, you're also meant to generally update it via .checked (then it's consistent with user interaction). What's being asked here is not something you can do with plain native checkboxes, so if React does something that enables it, how is that not deviating? But yes, React doesn't really fit the HTML model perfectly so it's fine, but I think there's quite clearly a native behavior.

Anyway, I don't want to derail this.

[sophiebits]

Why are you "meant to" update it with the property? .setAttribute() is an equal here.

[syranide]

If you want to simulate user input/filter/normalize/etc then you use the property so you don't change the initial value. If you want to replace the value (i.e. changing data source) then you use the attribute (similar to setting the key in React), you're "resetting" the checkbox in a sense. Again I agree this differentiation doesn't really work well in React (and there's no good reason to), but there is a difference.

I don't really mind, it doesn't really have any major implications, but it is clearly different from plain IMHO.

[jimfb]

Conceptually, upon every change, we throw away the entire page and rerender from scratch. Ideally, the output of an initial render should be identical to the output of an initial render followed by an update render, assuming the final state is the same.

[syranide]

@jimfb Yes, but it's a partial truth, inputs also have focus, selection, undo history, etc and in the context of this discussion, they also have an initial value that is reflected in the attribute. We currently control the lifetime of internal and external state via key in React and it makes sense, even for seemingly controlled components. If you don't agree with HTMLDOM reflecting the initial value in the attribute that is fine, it's a weird HTML quirk, but if interacting with a plain checkbox (attribute not updated) and a React checkbox (attribute updated) produces different results then React is doing something differently. Again, IMHO that's fine, but it is clearly deviating from normal HTMLDOM behavior.