Feature Request: Is there any possible to read other props in a specific validator function?

[JounQin]

As above, I want to validate a props data propA in the validator function and I want to read the props data propB so that I can judge whether they are valid together.

[petejohanson]

I can imagine a timing problem with this. If two properties are that closely linked, can you use an object property and validate the object's properties as a whole in your validate function?

[JounQin]

@petejohanson As I see, when the validator function being invoked, the props data propA and propB are both already prepared, right?

By the way, I separate the two props data because I want to use the basic validation by using {type, required}, and I did't find a solution to use them in a nested object.

[LinusBorg]

No, they are not. validator functions are called in a loop while setting up each prop one after the other.

So this could only work if

a) the props are in the right orde, or
b) we injected the array of all to-be-processed props into the assertProp() function -

But if we go with b), that would then be further complicated by things like Prop B depending on A, but A having it's own validator that invalidates A after B successfully validated with the previous value of A etc. pp.

In short, I think if you have to validate props that depend on each other, use the created() hook - here, all props are set up properly, and the component has not been compiled yet.

[JounQin]

I think the solution b) is OK. When I'm validating propA, I don't care if propB is valid or I can check it by myself but I just want to read it and do a further validation on propB.

And, I don't think it's a good idea to valid them together on the created() hook, it maybe a little dirty.

As I said, I did't find a solution to use the basic validation by using {type, required} in a nested object or array like the Flow type.

[fnlctrl]

@JounQin You can just set up a computed property to validate propA and probB and whatever props you want.

[JounQin]

@fnlctrl your solution is just like validating them together on the created() hook, but I think we should do the validation in a proper place rather than mixing it in our business logic.

[fnlctrl]

@JounQin I don't see using computed properties as mixing in business logic, though if you don't like it, you can write a mixin to validate props on beforeCreate hook, so the logic is separated.

[JounQin]

@fnlctrl What's the difference? My point is that the validation is just validation, why should we do that on any other hooks?

Of course we could do that right now, but it sounds strange to me.

[fnlctrl]

@JounQin
As @LinusBorg has said, the feature for prop validation depending on other props is too complex, error-prone (needs correct prop initialization order), not commonly needed, and cannot solve the problem of interdependent validation (propA requires propB, propB require propA). On the other hand, it's already easy enough to be implemented with computed properties. So in my opinion this feature shouldn't be included in vue since it's too user-specific.

Therefore my recommendations remain to be a). use computed properties. b). use a mixin to check inside hooks.