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> .

[evaldobratti]

@defcc @fergaldoyle any update on this?

[kgrosvenor]

I think casting to null would make sense for the number type, i'm used to AngularJS removing it from the object for me, but null would suffice as thats how i initially declare my model so that the text field isn't populated and placeholder text will also show if properties are null.

[blocka]

I also agree that casting to null would make more sense...
.number has a contract that you'll get back a number...if it can't be a number, it should be null...not an abrogation of the contract.

[edwardrbaker]

The workaround I used for numbers being an empty string when cleared out is the following. My .02 is that it should work like this as default, but maybe this will help someone else. (The property is cast as .toString() because of typescript)

    @Watch("viewModel.availableAfterDays")
    private numberOfDaysChanges()
    {
        if (this.viewModel.availableAfterDays !== null && this.viewModel.availableAfterDays.toString() === "")
        {
            this.viewModel.availableAfterDays = null;
        }
    }

[kgrosvenor]

Would love for this to be null it would make it consistent, this return of string is bound to create problems in projects and no one wants the workaround, but instead a fix and consistent type for empty models and null is best suited for this

[emfax]

+1 for returning null with v-model.number. As mentioned by @fergaldoyle, a .null modifier would be cool.

[networkimprov]

Please re-open this.

<input v-model.number="k" ...> should set k to null if the input is updated and then cleared.

null is the idiomatic Javascript to indicate that no value is provided. Various JSON parsers accept null for any field type, but not empty-string.

Given struct { int k; } this JSON does not decode: {"k":""} but this often does: {"k":null}

@defcc @posva

[joevandyk]

@defcc any chance this could get re-opened?

[popod]

By using v-model.number, I expect to have a number in any case.. returning an empty string is a nonsense for me !

Please reopen this issue or change this behaviour ..

Thanks :)

[posva]

The value is set to an empty string because that's what the HTML input gives. It still allows people to check if the input is empty by doing value === ''.
Yes, it would be more js idiomatic to do value == null but this would be a breaking change so it cannot be adopted on Vue 2 but will be considered in Vue 3
Locking as this is becoming just spam