You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Let's assume that both have some errors - to many objects, and too short string values at least in one of them.
The errors response we get is bidirectional, so we get either the array or the type one.
"errors": {
"people": [
null,
"people[1] must be at least 3 characters"
]
},
and
"errors": {
"people": "people field must have at least 3 items"
},
There are a few problems with this approach.
Usually we build some generic components on top of Field formik component to be consumable by different contexts, different pages. The component should contain validation conditions and proper styling. For this case we could use getFieldMeta to extract the errors and some other helpful indicators for this particular field. The problem is that getFieldMetarefers to the same name field (array one -> [people]), not the indexable one ([people.n)).
That being said a current implementation causes a ton of fleaky conditions to properly handle such a mechanism.
--
I'd see a least 2 solutions to this problem.
We'd have to change to contract of errors object so to contain some more contextual information
Helper methods (like getFieldMeta) should cover the nested, separate validations.
What do you think? Am I misunderstanding something or the reality is as I've described here?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Following question and potential conversation is the result of this formik sample code.
Let's imagine the Yup schema consists of typed array, both with some validation rules for array and its nested type.
Let's assume that both have some errors - to many objects, and too short string values at least in one of them.
The
errors
response we get is bidirectional, so we get either the array or the type one.and
There are a few problems with this approach.
Usually we build some generic components on top of Field formik component to be consumable by different contexts, different pages. The component should contain validation conditions and proper styling. For this case we could use
getFieldMeta
to extract the errors and some other helpful indicators for this particular field. The problem is thatgetFieldMeta
refers to the same name field (array one -> [people]), not the indexable one ([people.n)).That being said a current implementation causes a ton of fleaky conditions to properly handle such a mechanism.
--
I'd see a least 2 solutions to this problem.
getFieldMeta
) should cover the nested, separate validations.What do you think? Am I misunderstanding something or the reality is as I've described here?
Beta Was this translation helpful? Give feedback.
All reactions