Inaccurate warning when value props is set without onChange.

[mattmccray]

When you create an input component and set its value without providing an onChange handler, React will log this to the console:

"You provided a value prop to a form field without an onChange handler. This will render a read-only field. If the field should be mutable use defaultValue. Otherwise, set either onChange or readOnly. "

This isn't entirely accurate however. For example in my app I rely on event bubbling so that I can set a single onChange on the form component, thereby saving my sanity preventing me from having to add an onChange to every. single. field. (There are a lot in the app I'm working on)

[syranide]

@darthapo Two-way binding (valueLink) may be something you want to use instead, you can even implement your own this.linkState if the one provided (addon) isn't ideal for your case.

PS. Also, it's just a helpful warning, it's quite (OCD-)annoying that they can't be turned off though...

[mattmccray]

On a related note, I'm wondering... When making a custom control that needs to properly support onChange event bubbling, is there any good reason not to use:

var node= this.refs.control.getDOMNode(),
    fakeEvent= { target:node }
React.addons.TestUtils.Simulate.change( node, fakeEvent )

Or if there's no actual input element to propagate as the target, maybe:

var node= this.getDOMNode(),
    fakeEvent= { target:{ name:this.props.name, value:"NEWVALUE" } }
React.addons.TestUtils.Simulate.change( node, fakeEvent )

[Evernight]

Another problem with the same warning: Is there a specific reason not to allow onKeyUp and onKeyDown instead of onChange? I have value depending on the state of the component and want to intercept keyCodes to change it. Also I want a blinking cursor so readOnly is not an option. The workaround is to use empty function for onChange but would be nice to avoid it.

[syranide]

@Evernight It's only a helpful warning, it is not wrong not to have onChange. But yes, it is annoying that they can't be squelched, so they can end up burrying actually important warnings (or just generally be an annoyance).

[sophiebits]

@Evernight Can you post a simple example of what your code looks like? I wasn't under the impression that listening to keydown/keyup will work with controlled components. (By the way, how would you want to react if someone were to paste in text or move it around using the mouse, etc., in a way that doesn't cause key events?)

[Evernight]

@syranide Yeah, but it's nicer to have no warnings (especially at runtime) when there probably shouldn't be any.

@spicyj Here: http://jsfiddle.net/cf76B/5/ . It behaves exactly as I want it to, I am not exactly sure why it ignores the mouse events though.

[sophiebits]

@Evernight What do you mean, it ignores the mouse events? This is a strange case and you can write onChange={function() {}} to suppress the warning.

[Evernight]

@spicyj I mean I can't move text around or paste/delete the text using mouse. Probably some debugging would explain it but the current behavior suits my needs. Maybe the case is not typical indeed, I still can use empty function as a workaround.

[sophiebits]

@Evernight Yes, this is because you're not handling onChange. It sounds like you might want an uncontrolled component. See http://facebook.github.io/react/docs/forms.html.

[syranide]

This seems like a "wontfix" as it's only meant as a helpful warning, not an error.

[mczepiel]

How about extending support of implementing onInput or onChange?
In my case I didn't want to wait for a field to lose focus so I didn't have an onChange (I did put in a no-op to evade the noisy warning though)

UPDATE: FWIW the most significant usage of input is on an <input type="range>

Actually disregard this Sorry, the onChange normalization you've done mitigates most of my usage of onInput from some legacy code.

[ktei]

I came across this issue today as well. This is a bit weird because all I want is to set initial input values based on this.state, so there seems no particular reason for me to provide onChange in such case. Is this going to be fixed? Or, does it mean I'm doing anything improper?

[tirdadc]

@ktei you might want to consider using defaultValue for that purpose.

[ktei]

@tirdadc thanks for the advice. That works.