`v-model.number` will set data to string when input[type="number"] value is empty

[blade254353074]

http://jsfiddle.net/SebastianBlade/krbjt745/

When input value is empty, num will turn to string type.
Is it a feature? I think number data should be 0 when input value is empty...

[defcc]

It is an expected behavior. Vue will try to cast the string to number type, it will return the original string if it fails.

And it's also reasonable, or you will always get 0 after you delete the input value. As for your case, it's better to deal with it in the userland.

[blade254353074]

Number('') === 0

[defcc]

Vue.js uses parseFloat internally

[blade254353074]

All right

[kgrosvenor]

Why doesn't the attribute just get removed when its empty? This creates tons of casting errors really...

[kgrosvenor]

@blade254353074 looks like its not just me that doesn't agree that v-model.number should ever be returned as a string, i still hold strongly on thinking that the property should be removed from the object or turned null.

[blade254353074]

@kgrosvenor
Yeah~ when I met this problem, I didn't think it(empty string) was reasonable.

But...now I see
Their explanation is also reasonable.

Making difference between empty input and 0.

It's complicated when we only need number type, but it's useful when we need to know if user input or not.

You can use filters or computed to make this easier~

[gaiaz-iusipov]

I guess unexists value for the int typed property should be null instead of empty string.

[fergaldoyle]

Yes a [type="number"] which is emptied by a user should be null in my opinion. Setting it to empty string throws lots of type warnings if you have component props which expect Number

Or maybe there could be a v-model.null modifier which could be used in various scenarios to set empty strings to null if the user has emptied the input.

[aldencolerain]

@defcc I think this is still worth a conversation. I completely agree that casting to 0 seems incorrect, but what is the use case of this modifier? I think most people would use this thinking now I don't need the extra step of casting the string to an integer because some child component expects and integer not a string. But currently it falls back to a string which means you still need that extra code to ignore it if the cast fails making it significantly less useful. Is there a reason its not cast to undefined or null?

[defcc]

Thanks, I'll share with team and think it over. 2017-10-19 2:04 GMT+08:00 aldencolerain <notifications@github.com>:

…

@defcc <https://github.com/defcc> I think this is still worth a conversation. I completely agree that casting to 0 seems incorrect, but what is the use case of this modifier? I think most people would use this thinking now I don't need the extra step of casting the string to an integer because some child component expects and integer not a string. But currently it falls back to a string which means you still need that extra code to ignore it if the cast fails making it significantly less useful. Is there a reason its not cast to undefined or null? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4742 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACe7jhmbnSN-QctQQ2MVjmqdmimVAADoks5stj2_gaJpZM4Lmznz> .