Closed michaelwarren1106 closed 1 year ago
the delayedValidationTarget
test seemed flaky on my end locally. Would love to make sure its not something im doing wrong. Automated tests on GH seemed to pass for me tho. Might be something worth taking a look at? Seems like a race condition.
Fixed the validationMessage issue and added a test for it.
As of this PR, the validationMessage that is set will only ever be the message from the first invalid validator. The validity state will get passed though each loop, but not the message. This will enable messages shown as error messages to be "iterative" while the validity state is always full with multiple errors. This fix also prevents the issue where the last invalid validator message will always overwrite. So folks can "order" their validators in order of importances and ease of correction - for example having the requiredValidator be first and always show that message first if invalid.
Also noticed an error with the existing default validators. The
maxLengthValidator
was set to use therangeOverflow
validity key, but the correct key formaxLength
istooLong
. Similar forminLengthValidator
, the key was set torangeUnderflow
, but the correct key istooShort
.The
rangeOverflow
andrangeUnderflow
validity keys refer to themin
andmax
properties that deal with numbers.tooLong
andtooShort
deal withminlength
andmaxlength
and strings.