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
But it's wrong, it should avoid nested object properties if there is the combination of properties message + ref + type (because it means probably those properties are dedicated to an error so there is no reason to deep dive the HTMLElement from ref which could create circular loops).
Even with that it would be just an assumption I won't have a business case with those three properties as real form fields...
Finally I'm thinking about using control._fields and control._formState.errors and step by step compare the structure to be sure I'm addressing or not a real error.
Due to all the thinking, I'm wondering if such a thing should end in the library? Like a function returning all fields or intermediate fields having an error? (maybe I missed the solution 😄 )
Current solution
After testing different situations I noticed we cannot rely on control._fields since it does not contain arrays and so their children. Same for control._names that does not list the children.
I chose to end with the hack below just to keep a uniform logic.
exportfunctionrecursiveCountErrors(errors: FieldError|Merge<FieldError,FieldErrorsImpl<any>>|undefined): number{letcount=0;// `null` is of type `object` so checking this// Also, skip properties that would refer to the DOM element of an input since it has circular loops due to parent/children propertiesif(typeoferrors==='object'&&errors&&!(errorsinstanceofElement)){// A field could be named `message` so we make sure here it's an error and not a field to parseif(typeoferrors.message==='string'){count+=1;}if(Array.isArray(errors)){errors.forEach((error)=>{count+=recursiveCountErrors(error);});}else{Object.values(errors).forEach((error)=>{count+=recursiveCountErrors(error);});}}returncount;}
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
-
Hi,
I have complicated forms with nested objects and nested arrays, and in my case I would like to know how many errors there are in the form.
Using the basic
Object.values
is not an option, and since with.superRefine
the error message can also be on an array... it needs a specific logic.At start I did:
But it's wrong, it should avoid nested object properties if there is the combination of properties
message + ref + type
(because it means probably those properties are dedicated to an error so there is no reason to deep dive the HTMLElement fromref
which could create circular loops).Even with that it would be just an assumption I won't have a business case with those three properties as real form fields...
Finally I'm thinking about using
control._fields
andcontrol._formState.errors
and step by step compare the structure to be sure I'm addressing or not a real error.Due to all the thinking, I'm wondering if such a thing should end in the library? Like a function returning all fields or intermediate fields having an error? (maybe I missed the solution 😄 )
Current solution
After testing different situations I noticed we cannot rely on
control._fields
since it does not contain arrays and so their children. Same forcontrol._names
that does not list the children.I chose to end with the hack below just to keep a uniform logic.
Beta Was this translation helpful? Give feedback.
All reactions