New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issues with v-model.number #7136
Comments
The number becoming 1 is expected as that's what happens in js, they're the same numbers after all. If you need the zeros, you want a string, not a number. but it happens when the user changes focus which is IMO the ux you want here. About localization, it's handled by the browser and it's out of vue scope. It's the browser that makes some syntaxes work differently on different computers About your custom component, it behaves how you told it to behave, it modifies the value and adapt it to either cc @LinusBorg What was the part that you thought we might improve? |
Thanks for feedback! I've included plain Original post was more about how to make |
For now I don't see how it can be done without having 2 separate fields: 1 - string to keep |
That only happens with the custom input. The explanation is here:
v-model.number will cast values to Number or empty string, but you're of course free to create your own custom component that handles things differently using or not the |
Not only, see 1) case in fiddle (fill 1st input with 1.0000.0 ...), though it's for malformed value.
So is it not interesting to vue team to provide more type-strict interface? It's error prone and such errors are easy to leave, because there are no exceptions on misuse. Also to check that input is empty it's not enough to |
It does not happen with 1), or I'm not getting the instructions(typing 1.0000.0, then backspace x2).
No, it does not. It's either a number or |
Here is example: https://jsfiddle.net/hbov4mmr/8/
I'm not sure it's useful at all, because there is same value for empty string and for invalid value. In locales with |
Your example is completely different: the value is not initialized, it's as if you explicitly set it to undefined. Checking if an input is dirty or not is yet, another different thing, unrelated to numbers
That's the browser setting it to an empty string... Number validation is out of Vue scope Anyway, just waiting for @LinusBorg input on what could be improved |
Once again, this all is not about checking if an input is dirty, but about providing more solid and type-strict interface: if it returns numbers it should not return empty string or any other string. Returning empty string now is just a workaround, and i think it can be fixed. Can we please treat it more as feature request and ask few more maintainers look at it. I also wonder why I can not implement UPD. I was checking in chrome. In safari It allows to input |
@printercu Here's a try at making a numeric input component: https://codesandbox.io/embed/2wrqj87q0y?module=%2FApp.vue . It uses |
@lbogdan Looks great! Thank you! I've slightly changed and it also works with Can you please help with (from my previous comment):
|
- Reduces the number of times the UI is generating access tokens - Saving numbers is still an issue: vuejs/vue#7136 - TODO: Find a way to save integers by preventing them from being saved as strings
- Reduced the number of times the UI is generating access tokens - Simplified sub-forms; removed unnecesary field declarations - Saving numbers is still an issue: vuejs/vue#7136 - TODO: Find a way to save integers by preventing them from being saved as strings
- Reduced the number of times the UI is generating access tokens - Simplified sub-forms; removed unnecesary field declarations - Saving numbers is still an issue: vuejs/vue#7136 - TODO: Find a way to save integers by preventing them from being saved as strings
- Reduced the number of times the UI is generating access tokens - Simplified sub-forms; removed unnecesary field declarations - Saving numbers is still an issue: vuejs/vue#7136 - TODO: Find a way to save integers by preventing them from being saved as strings
- Reduced the number of times the UI is generating access tokens - Simplified sub-forms; removed unnecesary field declarations - Saving numbers is still an issue: vuejs/vue#7136 - TODO: Find a way to save integers by preventing them from being saved as strings
- Reduced the number of times the UI is generating access tokens - Simplified sub-forms; removed unnecesary field declarations - Saving numbers is still an issue: vuejs/vue#7136 - TODO: Find a way to save integers by preventing them from being saved as strings
- Reduced the number of times the UI is generating access tokens - Simplified sub-forms; removed unnecesary field declarations - Saving numbers is still an issue: vuejs/vue#7136 - TODO: Find a way to save integers by preventing them from being saved as strings
- Reduced the number of times the UI is generating access tokens - Simplified sub-forms; removed unnecesary field declarations - Saving numbers is still an issue: vuejs/vue#7136 - TODO: Find a way to save integers by preventing them from being saved as strings
- Reduced the number of times the UI is generating access tokens - Simplified sub-forms; removed unnecesary field declarations - Saving numbers is still an issue: vuejs/vue#7136 - TODO: Find a way to save integers by preventing them from being saved as strings
- All optional numeric fields are updated to null when they're an empty string - Scenarios only affects optional fields; it only happens when number fields are cleared - vuejs/vue#7136
- All optional numeric fields are updated to null when they're an empty string - The scenario only affects optional fields; it happens when number fields are cleared - vuejs/vue#7136
- All optional numeric fields are updated to null when they're an empty string - The scenario only affects optional fields; it happens when number fields are cleared - vuejs/vue#7136
- All optional numeric fields are updated to null when they're an empty string - The scenario only affects optional fields; it happens when number fields are cleared - vuejs/vue#7136
- All optional numeric fields are updated to null when they're an empty string - The scenario only affects optional fields; it happens when number fields are cleared - vuejs/vue#7136
With |
At the moment It's easy to reproduce, just go to https://vuejs.org/guide/essentials/forms.html#basic-usage and click "Try it in the Playground" and add |
v-model.number still doesn't work in firefox 125.0.2 but does in Chrome |
Version
2.5.8
Reproduction link
https://jsfiddle.net/50wL7mdz/79189/
Steps to reproduce
Included in fiddle
What is expected?
Input type='number' should not clear values, accept stings formatted in different locales. v-model.number should not return string.
What is actually happening?
Input value is cleared sometimes, v-model.number returns "" for "" and partially typed numbers.
This issue started with topic on forum https://forum.vuejs.org/t/extra-directive-for-number-inputs/22438, it was suggested to open an issue for that. Here is original post:
Hi!
I've found that
v-model.number
has limitations and requires some boilerplate in some cases. This is mostly becauseinput[type="number"]
returns''
for partially input numbers (like1.
). Here are some problems with it:[String, Number]
type.''
,undefined
, and0
are falsy values. This leads toval !== ''
checks in all places this attribute is used.2nd and 3d issues can be solved with computed property, but it's hard to implement for nested ones and array of values.
I came to using separate field for casted values:
I wanted to it implement with custom directive (like
v-model-number='obj.valCasted'
), but I see thatv-model
is handled differently by compiler. This way it can automatically use$set
when property is not defined on object. But I have not found how this can be implemented with custom directives.So here are questions :) :
input[type="number"]
?If not:
v-model
is?After that post I've tried to implement custom component, it's included in fiddle, but it also has some issues.
I've also added different types of inputs to fiddle to check their behaviour and checked against different locales.
Thank you!
The text was updated successfully, but these errors were encountered: