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
Current nature of validation will give an instant feedback upon any relative field input. Having a field marked in red isn't a supportive UX for a user trying to type in the value. I suggest to consider a more friendly flow.
Why
Granting more flexibility over when to display a validation feedback is a crucial part of effective fields layout. At the moment this possibility is somewhat limited to just invalid and errors properties.
How
I would prefer for the things to be configurable and dedicate this logic to the field component declaration. The end developer would be in charge of when to display error messages.
On the API level that would mean to establish something similar to "touched" fields.
Specification
A field record has a new touched property.
The default value of the touched property is false.
By blurring out of a field, its touched property becomes true.
Any further interactions with a field have no effect over the value of the touched property.
Reseting the field resets the value of the touched property to its default value.
Reseting the fields (on a form level) resets the value of the touched to its default value.
Explicitly setting errors via formRef.setErrors() sets the value of the touched property of the affected fields to true.
The text was updated successfully, but these errors were encountered:
Environment
What
Current nature of validation will give an instant feedback upon any relative field input. Having a field marked in red isn't a supportive UX for a user trying to type in the value. I suggest to consider a more friendly flow.
Why
Granting more flexibility over when to display a validation feedback is a crucial part of effective fields layout. At the moment this possibility is somewhat limited to just
invalid
anderrors
properties.How
I would prefer for the things to be configurable and dedicate this logic to the field component declaration. The end developer would be in charge of when to display error messages.
On the API level that would mean to establish something similar to "touched" fields.
Specification
touched
property.touched
property isfalse
.touched
property becomestrue
.touched
property.touched
property to its default value.touched
to its default value.formRef.setErrors()
sets the value of thetouched
property of the affected fields totrue
.The text was updated successfully, but these errors were encountered: