I’ve been working for some time already on a form package and finally I felt ready to release a few of days ago, I’ve posted on slack but I might as well cross post here.
the form is takes queue from the all encompassing and batteries included mindset of some form libraries from Ruby and other languages. But don’t expect lack of control, because it also intends to offer extensive rendering and localization customizations.
Fields can be pattern-matched against, name, type or any other attribute and it’s default rendering overriden (see interactive docs customization section). It intends to be a comprehensive solution for building, parsing, validating, and rendering forms.The parsing API is modeled after Json.Decode with type-safe decoders (map, mapN, andMap, andThen) to transform form inputs into custom types. The building API is inspired by elm’s Html API.
Built-in validators (required, min/max values, text pattern, etc.) + custom validation support
Dynamic forms can be built from JSON specs and form data can be converted back to JSON for backend submission with no parsingCheck out the interactive docs: https://form-toolkit.bitmunge.com (thanks elm-book!)
Thank you <3
In the context of the package there is some overload in terminology between parsing and validating, you can construct a field passing the Attributes Field.require, Field.min, Field.max or Field.pattern and this validations will continually run but will not always be shown.
I took some UI decisions I thought were sensible in terms on when to display the errors: an error notifying that a field is required will only show on blur, same as when pattern is provided and the field does not satisfies the pattern, this is to prevent distractions when inputing text that doesn’t yet match a pattern. min and max errors are shown immediatelly when the input is out of bounds.
Field validation errors will make parsing fail, parsing failure will accumulate all errors for all fields and using Field.parseAndUpdate is possible to add custom validation errors.
In short: yes, validation related to attributes is always ran but errors are not always visible depending on the field state of pristine, focused or blurred,Field.parseAndUpdate will update the fields and also display parsing errors as field errors, to render all validation errors, on form submit for instance, is possible to use Field.touch to display all errors that would only been visible when the an input looses focus.
I believe that by checking the guide you will get a good sense on how does validation attributes works.
I would be very interested in having feedback in terms of the UI behavior decisions related with error display or otherwise, and how could this be customized if required, of course there is opinions baked in to the package, but I want to provide defaults while keeping flexibility.
! I will give this a try in my next project!