-
-
Notifications
You must be signed in to change notification settings - Fork 33.7k
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
Supply all props to validator as second argument #6787
Comments
I gave this a shot and while it's possible to add I think it could introduce some inconsistent behaviors or complexify further the validation. For example, it's weird when used with a type because you expect both rules to validate, of course, you could say that the user is responsible for the type validation inside of the validator, we could even add a warning for that, but some people may want to use both at the same time. It's a bit similar with the |
I'm not sure I follow your concern @posva. I don't see this feature effecting the current behavior of |
no, they wouldn't required: ({a, b}) => a || b But this should be stripped off on production 🤔 |
Damn, I see your concern now... If one of two props is required, but neither are passed in, neither validator will ever run and no warning will be thrown. A dedicated function might be a better place for this, I'll keep brainstorming APIs. Thanks! |
Closing since it seems we were not able to find a good solution for the concerns, and it is possible to implement the logic in lifecycle hooks (e.g. |
What problem does this feature solve?
Right now (2.4.4), props can be validated based on their value, but are unable to take other props into consideration. With access to a props object, we could do more complex validation.
For example, imagine a component with a
foo
andbar
prop, where at least one of these props must be defined. Currently, this logic would have to be placed in the component's lifecycle hooks or render function. I would like the ability to keep it within thevalidator
functions, as I think it's a more appropriate place for the logic.What does the proposed API look like?
The text was updated successfully, but these errors were encountered: