Validation should take keep track of dirtyness

[Harro van der Klauw]

Was implementing this myself when I decided to do a quick check if it wasn't already done, great work.

But it's kinda ugly to show all those error messages to a user when they haven't even typed a single character yet.
So either for schema validation put a isDirty flag on the field data right next to isValid or don't even validate if model[field] === initialModel[field]

[David Zukowski]

Thanks for checking it out, I appreciate your thoughts. You're totally right, however I intentionally ignored the rabbit hole of more intricate (read: correct) form validation as there too many things to consider and this was really meant as a proof of concept.

It would be fairly trivial to implement a isDirty flag on each field, which I think would be the ideal route since initialModel[field] === model[field] is not necessarily correct (initialize w/ empty password, they type something in, delete it; fields are now the same, but invalid).

I'd be open to considering improvements in this regard, though the purpose of this library is almost exclusively to supply the model + getter/setters for it from a higher order component. The rest of the functionality is demo'd to show it's possible, but expected to be more thoroughly implemented in userland.

[Arend van Beelen jr.]

The way I've implemented this for myself (using reformed as base) is to create a validationFeedback middleware. This creates a higher-order component that provides two props: getErrorClass and showValidationFeedback. getErrorClass is what I use to display an error indication on my form fields and returns a CSS class name to be fed into classnames. The trick is that it never returns a CSS class until showValidationFeedback has been called at least once. I call showValidationFeedback when the user clicks the submit button (which is always enabled for these forms) and I also use this function to display textual error messages in a ticker and to move focus to the first field with an error.

Of course this approach already makes some assumptions about what your actual form implementation looks like, so your mileage may vary, but hopefully this gives you some ideas.

[David Zukowski]

Thanks for the suggestion @arendjr, that sounds like a pretty sane approach.

I'm going to close this issue just to tidy up the project some, since it's more of a discussion than anything. I'll direct people to your suggestion if this comes up again :).