Vuetify Version: 2.0.2
Last working version: 1.5.0-1.5.0-beta.1.0
Vue Version: 2.6.10
Browsers: Chrome 75.0.3770.142
OS: Linux x86_64
Use the example in docs
Value can be emitted without the mask.
Option to emit value.
https://codepen.io/neanderthil/pen/ZgKGKj
This used to work before the 2.0 upgrade with the built-in masks. With the removal of those in 2.0 the 3rd party library directive solution is inadequate.
Possible solution would be a slot for custom input text where we could use the vue-the-mask component
Thanks
Related to PR: https://github.com/vuetifyjs/vuetify/pull/7304
vue-the-mask exports its masker function. so if you need the unmasked value you can do
import { masker } from 'vue-the-mask'
...
const unmasked = masker(maskedValue, mask, false)
earlier I did experiment with adding a way to do this
<v-text-field v-mask="mask" v-model="value" @unmasked="...">
by check vnode.data.on.unmasked
in the directive and calling it with the unmasked value. it works, but not sure if it would be of much greater use than manually unmasking when you need to.
Hi @nekosaur!
I think the removal of mask functionality should be mentionned somewhere on the release notes of v2.0. This is a breaking change for some user and it's not documented!
Thanks
It is definitely a breaking change and should be mentioned. It has been added to release notes.
@nekosaur are u sure it exports masker? I dont really see. I see only
{
TheMask: [Getter],
mask: [Getter],
tokens: [Getter],
version: [Getter],
default: [Function: r]
}
https://github.com/vuejs-tips/vue-the-mask/blob/master/src/index.js#L11
Sorry, I was apparently looking at a fork (https://github.com/RonaldJerez/vue-the-mask). Perhaps we should try to find a better alternate 3rd party library since vue-the-mask has been pretty dead for more than a year now.
@nekosaur Stumbled onto this breaking change today, tried the vue-the-mask route but ran into the same problem with model being masked. Tried with v-mask (https://github.com/probil/v-mask) as plug-in and work as intended.
Good to know. I'll try it out and see if I can update the documentation to use that instead of vue-the-mask
last time i tried probil/v-mask when vuetify 2 was in beta it wasnt working for vuetify, good that its fixed then :)
@vincentauger I just looked at v-mask, and it seems to function the same as vue-the-mask? i.e. it does not allow you to get the unmasked value. It does not export any unmask function.
@nekosaur You are correct, I made a silly mistake after trying too many work around last night and left a computed value that manually unmasked it in my tests, sorry about this. I'll keep searching here.
Why was the mask feature (which I consider critical for UX, as well as keeping incoming data clean) removed and delegated to third-party libraries? It just adds another dependency to worry about.
Basically our mask implementation was buggy and rather limited, and there are other options available that many people have needed to be using anyway.
@diazemiliano not really a regression, this was intentionally removed.
I understand, but this caught a lot of people off guard. Based on the chat log you posted, you guys discussed this internally and made a decision to remove the feature. It would have been great if you had first solicited comments from the actual users though. You would have gathered valuable feedback, and who knows, someone may even have stepped up to maintain the feature moving forward.
In addition, I think in these situations you should first make sure that the other options that are available have feature parity before removing the feature from Vuetify. Otherwise you're simply passing the aforementioned technical debt to your users. In this particular case, none of the third-party libraries out there seem to emit the unmasked value (I think I tried six or seven before giving up). This means the unmasking needs to be performed manually post-emit, which gets real messy.
I love the work you guys are doing, and Vuetify in general is fantastic. 2.0 especially has been a total slam dunk. <3 But when it comes to feature removals, some sort of standard operating procedure, developed in collaboration with the community, would be great to have. Not just a "we will mention this in the migration documentation" but a more inclusive discussion with the community.
Looks like this particular issue was actually brought up by one user during beta, but nobody really complained further about it. We do try to get feedback where possible, but it's hard to tell how people are actually using features if at all.
I don't think we're actually opposed to adding masking back, but it would definitely have to be done in a more maintainable way. The previous implementation was done by a community member and made it difficult to fix other text field problems due to how tightly coupled it was to everything.
Does anyone have a workaround at least? I'm really not looking to manage this manually.
Currently, I鈥檓 unmasking using regex and a computed value as a work-around.
For example:
unmaskedPhone() {
return this.user.phone_number.replace(/\D+/g, "")
}
How to remove v-mask directive for custom component, i need to don't mask the input some times but if i send v-mask="" don麓t work any idea ??
How to remove v-mask directive for custom component, i need to don't mask the input some times but if i send v-mask="" don麓t work any idea ??
Hello any update for this issue i didn't recibe any feed back could you help me please
Also when i send the default to v-mask empty string i can write anything and i don't expect that behavior
I understand, but this caught a lot of people off guard. Based on the chat log you posted, you guys discussed this internally and made a decision to remove the feature. It would have been great if you had first solicited comments from the actual users though. You would have gathered valuable feedback, and who knows, someone may even have stepped up to maintain the feature moving forward.
In addition, I think in these situations you should first make sure that the other options that are available have feature parity before removing the feature from Vuetify. Otherwise you're simply passing the aforementioned technical debt to your users. In this particular case, none of the third-party libraries out there seem to emit the unmasked value (I think I tried six or seven before giving up). This means the unmasking needs to be performed manually post-emit, which gets real messy.
I love the work you guys are doing, and Vuetify in general is fantastic. 2.0 especially has been a total slam dunk. <3 But when it comes to feature removals, some sort of standard operating procedure, developed in collaboration with the community, would be great to have. Not just a "we will mention this in the migration documentation" but a more inclusive discussion with the community.
I'm terrified with this, remove a feature without asking the community. I don't even think migrate version 2 now. I had many issues doing the decimal mask, the mask that came with vuetify was just perfect for the other cases. I think this is a great lost for the project. Vuetify is awesome, I love you guys but we need to talk when the subject is removal of features, maybe deprecate and remove in a next version?
Commit => https://github.com/vuetifyjs/vuetify/commit/0cecd4a5dc3aed38470ba2a5cf4ab6672d306ac1
Just wanted to point out that this causes the mask + counter used together to not work as expected with any of the 3rd party masking libraries (vue-the-mask, vue-input-facade, vue-mask and vue-mask-directive). This was working correctly in vuetify 1.X with the built-in mask feature.
would it be possible to release the feature as an optional component? so that users who want to use it, can jsut drop it in their project at their own risk? maybe customize it or something? as far as i've read, none of the alternatives returns unmasked values. the vuetify one did, so maybe someone could release it on its own? i'm not sure if i'd want (or could) write a solid replacement myself
Most helpful comment
Why was the mask feature (which I consider critical for UX, as well as keeping incoming data clean) removed and delegated to third-party libraries? It just adds another dependency to worry about.