[V1] QInput type="number" returns string instead of number for model

[topvis]

codepen link

quasar: 1.0.0-beta.17,
@quasar/app: 1.0.0-beta.18,
Browser: Chrome
OS: Windows 7

QInput with type="number" returns string instead of number. Type in any number or change the value of the QInput by clicking the up/down button will return a string value.

There was a fix #2605 for V0.x. But seems V1 hasn't got this issue fixed. Or maybe this is intended by design?

[rstoenescu]

Thanks for reporting this. Will get it fixed.

[rstoenescu]

Prior to a thorough investigation, I recommend using:
<q-input type="number" v-model.number="model" ...

[topvis]

Oh, I didn't know that. I'll try it. Thanks.

[rstoenescu]

This is the recommended usage going forward.
Docs will be updated along with the release of beta.18

[topvis]

What would be the best way in the case of one-way binding? E.g.,
<q-input type="number" :value="data" @input="updateData"/>
Should the type cast be done in the event callback function "updateData"?

[rstoenescu]

@topvis That's not one-way binding. That's the rough equivalent of v-model.
If you use this equivalent, then yes, you need to do the cast in your updateData. But it's not just a matter of casting string to number.. But you can use v-model.number and still listen to the @input event to trigger your specific method.

[topvis]

@rstoenescu I had to use the @input event because the data is actually in a Vuex store and I need to call a Vuex mutation function to update the data. I assume this is a very common way when using Vuex?
I would propose to add a line or two in the Docs to explain that user needs to cast the string to number in the @input callback function.

[rstoenescu]

Use a computed property with a setter and getter when dealing with a Vuex store.

// ...
computed: {
  message: {
    get () {
      return this.$store.state.obj.message
    },
    set (value) {
      this.$store.commit('updateMessage', value)
    }
  }
}

[lopugit]

@rstoenescu I had to use the @input event because the data is actually in a Vuex store and I need to call a Vuex mutation function to update the data. I assume this is a very common way when using Vuex?
I would propose to add a line or two in the Docs to explain that user needs to cast the string to number in the @input callback function.

yeah that's how I do it, :value + @input and @rstoenescu computed props aint an option because it's way to slow having to write boiler plate for every vuex store value you want to use, the :value + @input hack has been a real lifesaver

[rstoenescu]

@lopugit this is the Vuex way. If you use the equivalent form of v-model (:value + @input) then you miss on v-model's handling of the number..

[lopugit]

@lopugit this is the Vuex way. If you use the equivalent form of v-model (:value + @input) then you miss on v-model's handling of the number..

all g, how do they handle numbers? just a parseInt or more sophisticated?

[rstoenescu]

@lopugit very sophisticated. wish it were that easy to parseInt() only. Example: imagine parseInt() when user has typed "0." --> NaN. Or wanting to type (0.10004) --> typing "0.10" will turn this into "0.1" (you'll never be able to type full 0.10004). And the examples can go on and on and on and on.

[lopugit]

@lopugit very sophisticated. wish it were that easy to parseInt() only. Example: imagine parseInt() when user has typed "0." --> NaN. Or wanting to type (0.10004) --> typing "0.10" will turn this into "0.1" (you'll never be able to type full 0.10004). And the examples can go on and on and on and on.

Ahh very interesting, can always copy the handler code :P

[rstoenescu]

Just thought you should be aware of what it does :)

[lopugit]

Just thought you should be aware of what it does :)

I know I'm very thankful, I've been wondering <3

Also v1 is sick ;)