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
Is your feature request related to a problem? Please describe.
Limitations of the current addField functionality results in an inconsistent validation experience when the provided selector matches fields that may have existing rules applied already. It will validate when "forced" (e.g. upon form submission), but does not detect both rules when the field is "touched".
For example, I might register addField('input[min]', ...) and addField('input[max]', ...) separately (as part of a library of generalized rules), but currently, the system applies validation only to the first matching rule, rather than allowing all relevant validation rules to be applied. This limitation forces me to handcraft hyper-specific logic for individual forms and their fields instead of constructing generic, reusable validation rules that may overlap.
Describe the solution you'd like
I would like the validation logic to be extended so that when a form input matches multiple registered fields or "rules," all relevant validation rules are applied. This would allow addField to behave more like addRule, enabling fields that match multiple rules (e.g., an input that supports both min and max constraints) to be validated against all the rules they match, rather than stopping at the first match. I've opened PR #150 with code that I believe resolves the issue (sorry if opening the PR jumped the gun on approving this idea!)
Describe alternatives you've considered
An alternative would be to build custom, handcrafted validation logic for each form, but this approach sacrifices reusability and modularity. Another option could be registering composite rules (e.g., input[min][max]), but this still requires anticipating every combination of constraints, making it less scalable.
Additional context
While the max/min example is perhaps a bit trivial, you can imagine the potential if I were building out a more comprehensive form wrapper for my projects that may include several rules that may or may not overlap in various scenarios, or more dynamically constructed forms with CMS control.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Limitations of the current
addField
functionality results in an inconsistent validation experience when the provided selector matches fields that may have existing rules applied already. It will validate when "forced" (e.g. upon form submission), but does not detect both rules when the field is "touched".For example, I might register
addField('input[min]', ...)
andaddField('input[max]', ...)
separately (as part of a library of generalized rules), but currently, the system applies validation only to the first matching rule, rather than allowing all relevant validation rules to be applied. This limitation forces me to handcraft hyper-specific logic for individual forms and their fields instead of constructing generic, reusable validation rules that may overlap.Describe the solution you'd like
I would like the validation logic to be extended so that when a form input matches multiple registered fields or "rules," all relevant validation rules are applied. This would allow addField to behave more like addRule, enabling fields that match multiple rules (e.g., an input that supports both min and max constraints) to be validated against all the rules they match, rather than stopping at the first match. I've opened PR #150 with code that I believe resolves the issue (sorry if opening the PR jumped the gun on approving this idea!)
Describe alternatives you've considered
An alternative would be to build custom, handcrafted validation logic for each form, but this approach sacrifices reusability and modularity. Another option could be registering composite rules (e.g., input[min][max]), but this still requires anticipating every combination of constraints, making it less scalable.
Additional context
While the max/min example is perhaps a bit trivial, you can imagine the potential if I were building out a more comprehensive form wrapper for my projects that may include several rules that may or may not overlap in various scenarios, or more dynamically constructed forms with CMS control.
The text was updated successfully, but these errors were encountered: