I don't know if this is silly or I miss something but pressing the enter does not trigger an onChange/onInput on text inputs.
Sorry. I got it using onKeyDown/onKeyPress.
Ok. Seems like a theres some inconsistencies here. When I used only onKeyDown/onKeyPress, it captures 'enter' key but does not have event.target.value, while onChange/onInput does not capture enter key but provides the event.target.value. Do I really need to specify onChange and onKeyDown at the same time?
@sydcanem: could you provide a jsfiddle that let us reproduce what you are seeing? Thanks!
@sydcanem To the best of my understanding, onChange and onInput (theorically) occur after the fact and only notify that the input has changed (so only in a textarea will it trigger those events). onInput _sounds_ like it should have something do with keyboard input but is just an instant version of onChange, but in React it's as far as I'm aware virtually the same as onChange. So yeah onKeyDown etc is the right way to go for listening to the keyboard (however, you will want to use preventDefault to prevent pinging sounds for enter).
However, event.target.value should be set in onKeyDown, if a field is focused. I just tested this myself and it works for me, so perhaps there's something else going on?
PS. In the next release of React you will be able to use event.key === 'Enter' instead of magic numbers for which/keyCode.
@vjeux http://jsfiddle.net/sydcanem/RhLNy/1/ using onKeyDown. Does not get the inputted text.
@sydcanem Ah you are totally right yes (onKeyInput happens BEFORE input, so that you can preventDefault it), I had forgotten about that. But I'm curious, any reason why you need the text AND know the enter was hit? The enter shouldn't emit any characters.
Submit on enter?
Did you forget to save your jsfiddle?
@sydcanem Yeah, but since the enter won't actually emit any characters/change the value, you can just read event.target.value? (and again, you will want to preventDefault the enter to avoid pinging sounds for the user)
Also, in your fiddle, just read this.state.text instead of from the DOM node.
Aha, I get your problem now that I actually looked at the fiddle. One sec.
@spicyj I just did.
@syranide So I just read the event.target.value in onChange ? But enter does not trigger an onChange.
@sydcanem Ah, I see your problem now! You need to handle the text input events in an onChange handler and handle the enter key in a separate one. See this example: http://jsfiddle.net/spicyj/HdR6E/.
@sydcanem Yeah, I just checked your fiddle and see what you mean. The solution is to listen to both events... OR, make it uncontrolled, then you only need to listen to one (but you'll have to use the DOM node directly) ... OR, you can use ValueLinkState or whatever it is called, which is basically a controlled input that is bound to a variable (it does onChange event for you).
@spicyj That's what I did as of the moment. I was hoping there's some other event I could listen that both handles the situation.
@syranide 'valueLink' is using onChange so it does not also handle enter keys. I think listening on both is the best solution for now.
There isn't a single event that handles both. Why? Because there are ways to input text that don't involve the keyboard and so onChange and onKeyDown are conceptually separate.
@sydcanem you can use valueLink so that you don't have to listen to the onChange event, you still need to listen to the onKeyDown.
@syranide Got it. So it saves me adding and onChange handler.
@spicyj I get what you mean. But isn't onKeyDown suppose to have the inputted key in the event.target.value?
@sydcanem Nope, because onKeyDown happens before the input is changed, so that you can prevent it from affecting the input. If you preventDefault everything in onKeyDown then nothing will ever be inserted into the input. Thus, event.target.value will have the current value of the input, which does not yet include the pressed key.
@syranide I see now. Thanks for helping.
@spicyj Thanks.
I tried fixing a related issue in the flux chat example: https://github.com/justin808/flux/commit/643ca19b68ec63170648e9f5cba2456aba23a92c
Feedback would be appreciated. :-)
same issue for spaceBar
could you plz help me
Most helpful comment
@sydcanem To the best of my understanding,
onChangeandonInput(theorically) occur after the fact and only notify that the input has changed (so only in atextareawill it trigger those events).onInput_sounds_ like it should have something do with keyboard input but is just an instant version ofonChange, but in React it's as far as I'm aware virtually the same asonChange. So yeahonKeyDownetc is the right way to go for listening to the keyboard (however, you will want to usepreventDefaultto prevent pinging sounds for enter).However,
event.target.valueshould be set inonKeyDown, if a field is focused. I just tested this myself and it works for me, so perhaps there's something else going on?PS. In the next release of React you will be able to use
event.key === 'Enter'instead of magic numbers for which/keyCode.