react: Controlled number input doesn't handle e, - and . properly

A controlled number input, without a corresponding setState function, still allows e, - and . to be entered (and numbers can be inputted afterwards). I could be incorrect but I don’t believe this is the desired behavior.

Here’s a JSFiddle demonstrating the issue.

About this issue

Original URL
State: closed
Created 8 years ago
Reactions: 1
Comments: 18 (12 by maintainers)

Commits related to this issue

resources/autoscaling: stricter validation for percentage inputs It turns out that <input type="number">'s builtin validation is more of a hint than a constraint, and not really reliable. See for ins... — committed to sapcc/elektra by majewsky 5 years ago

Most upvoted comments

FWIW I should mention, using tel as the input type rather than number allows many of the same benefits number brings, without as many (if any) of the drawbacks illustrated above.

Using tel still allows mobile phones to display a number pad input, and it’s a little closer to semantic ‘truth’ than ‘text’, but obviously still not ideal.

It’s the way I overcome this in my usage: https://github.com/TwilightCoders/Card-Games/issues/13#issuecomment-410089142

JimmayVV on Aug 2, 2018

This should be addressed in 15.5, now that we’ve merged the number input PR: https://github.com/facebook/react/pull/7359#event-1017024857

nhunzaker on Mar 27, 2017

It looks like this happens because Chrome reports the value as an empty string: https://codepen.io/nhunzaker/pen/mMWdNV?editors=0011

So React sees that the value hasn’t changed, so it doesn’t assign the value property. Unfortunately React has to avoid touching input.value if the value is the same to avoid input validations that cause nasty side-effects like dropping decimal places and expanding things like 1e2 into 100.

I don’t know what to do here. Is this a bug?

cc @jquense @aweary for discussion.

nhunzaker on Aug 7, 2017