2.5.16
prop value should be default if validator is returning false
validator is ignored
"validator" feature does serve any purpose if it its return value is ignored nor usable anywhere else in the component.
That's intended behaviour.
If a requirement isn鈥檛 met, Vue will warn you in the browser鈥檚 JavaScript console. This is especially useful when developing a component that鈥檚 intended to be used by others.
That's the intended usecase. nothing more.
The documentation never stated that props validator would have any side effect other than a console warning in development build.
You might need computed properties in your use case.
You might want to use something like https://github.com/posva/vue-coerce-props to force a prop to a specific value
@LinusBorg @sodatea thank you for your quick answer. i understand the statement, but i think the validator feature has no meaning as currently it doesn't prevent the component from misbehaving. I also understand that computed value could be a better option for now, although some may wonder why validators exist and why computed values are used as validators.
@posva thank you for this, i think it's exactly what i was looking for. as a personal opinion i wonder why this is not a core feature of vue as it makes more sense than validators as they currently are.
@y-nk It was in v1 but removed in v2.
https://vuejs.org/v2/guide/migration.html#coerce-Prop-Option-removed
There are a few advantages (of computed properties):
- You still have access to the original value of the prop.
- You are forced to be more explicit, by giving your coerced value a name that differentiates it from the value passed in the prop.
Because coercing is just a computed property and we don't want to add another API to do the same thing :smile:
I created the package because the feature existed in Vue 1 and some people find this more expressive but it can actually be harmful to new developers, so beware
i think the validator feature has no meaning as currently it doesn't prevent the component from misbehaving.
Do you develop with a minimized version of Vue that doesn't give you any warnings? I don'T think so. You use the version that gives you warnings during development because warning hve meaning to you.
That's the "meaning" of this feature: give warnings if props values don't pass the validator.
sorry that i didn't check the migration guide and docs more carefully.
@sodatea ok i get the advantages and agree with them. my only after thought would be that "real computed values" and "computed values from validation" will be written in the same space (the computed block), which gives 2 _meanings_ to it... but then @posva 's package solves this.
@posva i've read the package's readme ; it's harmful only if using $coerced in a coerce function, so i think it's kinda ok (right ?). it feels more natural for me to separate prop validation from computed properties ; it's also more readable since each coerce prop definition is written inside the prop definition block rather than apart in the computed block, which could be (sometimes a lot of) lines away.
@LinusBorg I understand the point : validators are a _development_ tool and not _real life_ validators intended to have impact on the component. It didn't feel this way at first since the wording "validator" looked very "practical production oriented" to me, but I guess i should have read the doc a second time (sorry for that).
You can try to computed the attributes. It looks clearer.
computed: {
computedVal() {
const { someProp } = this;
if (someProp < 50) return 0;
return someProp;
},
},
template: '<span>{{ computedVal }} </span>'
Most helpful comment
The documentation never stated that props validator would have any side effect other than a console warning in development build.
You might need computed properties in your use case.