Deleting first digit of otherwise all-zero number makes input zero
Closed this issue · 7 comments
If you enter a single digit followed only by zeros, such as 10000, move to the first position and delete the first character the input turns to 0.
I don't think this is expected behaviour, as you might enter 1000000 and want to change it to 2000000 by moving to the start, deleting 1 and replacing with 2 in which case you end up with just 2. It's also not how the native HTML number input works (which keeps zeros). I personally keep running into it.
Humm.. I agree. But this has been added to remove extra 0's from the starting. I have to see how NumberFormat can smartly identify if the user's intention is to change the number.
One possible way I can think of is to keep zeros while anything got removed, but as soon we type something do the extra zero formatting. I will evaluate this idea if it doesn't break anything else.
What about removing leading zeros on blur only?
@pandaiolo Seems like a nice idea. I will try that out.
This will also require a change in the way a thousand separators are applied.
A number will look something like this 0000123,234 while 0s are not removed. But I think that should be ok. What do you say?
Good question. I suppose this will most usually occur with the usage described by @victorandree. Let's say you go from $1,000,022 to $2,000,022 by erasing the first character. In a classic manual input, it would go through the intermediary value $|,000,022. (| is the caret)
Here, in the case of a controlled input, the onChange intermediary value would be 22, as expected - even if the label keeps the leading 0s for UX, they are mathematically useless.
Therefore, the last-formatted-value might be needed internally to understand the user intent and successive input value. Initial value prop of 22 would display $22 but value prop of 22 in the above example, with internal previous state (incl. caret position), would stay $|,000,022 (like if I was correcting that in a text editor, $|000,022 is also OK I suppose).
Another example, if the user corrects $1,000,022 to $200,022, there will be additional intermediate values. $|000,022 and $|00,022 if using suppr key, or a case more similar to the first example if using backspace: $1|00,022 and $|00,022.
To answer the question :) I guess it would be better to keep thousand separators in the leading 0, except maybe a prefixing one, as it ressembles more a manual input behavior. Not sure if it's easy to achieve though! Otherwise, 0s without separators are still better than no 0s at all!
Thank you anyway!
Handling this on onBlur event, in onChange event we will keep the intermediate state. This required addition of onValueChange props in place of onChange prop, as calling onChange prop with blur event is not right.
"Here, in the case of a controlled input, the onChange intermediary value would be 22, as expected - even if the label keeps the leading 0s for UX, they are mathematically useless."
For controlled input I guess its ok to have intermediary value in parent state as on onValueChange fired by onBlur that will get corrected. Keeping it different then what we show as UX can cause a lot of inconsistency cases.
Changes available on v3.0.0-alpha3
Seem to work pretty well. Thanks for this update!!