v-model.number modifier should validate that input is a number before converting

[06b]

Version

2.6.6

Reproduction link

https://codepen.io/anon/pen/YBbBKz

Steps to reproduce

Change the value from '1e2' to '1e2w'

What is expected?

Because 1e2w is not a valid number it should not convert it.

What is actually happening?

1e2 is a valid number and gets converted to 100, however 1e2w is not - because parseFloat is used internally, it drops the w and assumes that the value is 100.

---

I was using vee-validate trying to validate that an input was numeric and it was discovered that it viewed an invalid input such as 2qwerty - this was because the .number modifier makes it think that it's 2 - so it never fires validation that the input is invalid.

If the .number modifier were to confirm that the value entered was a valid number for example !isNaN(val) and then attempt parseFloat I think that would handle it.

[flozero]

https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Objets_globaux/parseFloat
As It is something coming with the parseFloat spec and so transform by him.

Vuejs will receive the parse number so it will work normally.

export function toNumber (val: string): number | string {
  const n = parseFloat(val)
  return isNaN(n) ? val : n
}

Internally it look's like this.

If you want something more consistent you should use some custom validators as you did with vue validate and not use the number modifier.

Changing the order of the parseFloat and isNaN is not relevant

[yyx990803]

The number modifier by definition uses parseFloat to parse any string that starts with a valid number and casts to that number. Changing this behavior is a breaking change so it's a no-go.

[06b]

I understand that what is currently happening with parseFloat is based off the spec. Currently I'm having to do what you have described, which is remove the number modifier and use a custom validator.

The reason I created this bug is after spending some time to debug the issue which I originally thought was with a third party validator, I then discovered it was due to the .number modifier. I tried searching the issues but most of what I saw was people saying how you could still enter the letter e when doing <input type="number" v-model.number="val"> (which is valid according to the spec) however I did see issue #5531 where this behavior causes issues with another validator as well.

So when I saw issue #7136 I wasn't sure if this could be considered as part of the discussion or if this might be something up for consideration in Vue 3 since it would be a breaking change (Example of what I was thinking of earlier when I first created this issue [Not sure if something like this would allow third party validators to catch that the input isn't numeric]).

Either way I figured it would be worth posting incase someone else runs into the same issue in the future. Thanks for taking the time in replying 👍

[flozero]

It's all time ok to ask questions I think ˆˆ. But yeah it's like a breaking change and a modifier by definition just do one thing.
Here cast the string into number. If you start to add more than one capability it is not modifier anymore :).
Then you can create your own modifier or some validator 👍