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
This could actually be added without breaking backwards compatibility. A multimethod could convert vector validations to hash map ones. It would be a bit hacky, but I think not breaking compatibility is important.
This has other benefits, like being able to style certain form fields according to their validations (asterisks next to required inputs, etc).
The text was updated successfully, but these errors were encountered:
I'm working on a patch for this.
Why would you want to use a multimethod for the conversion from vector to map?
I've just built a function for the conversion.
Should I update the readme to describe the map-based validation format and only mention the vector-based one briefly?
Was thinking multimethod because the validation elements (keys, args, etc) can be in different positions depending on the type of validation. The multimethod would dispatch on the first value in the vector. It would also work for custom validators not defined in verily. Otherwise all special cases would need to be hard coded into the fn.
To get the benefits of a format that can be operated on generically, validations should be maps, like Formative field specs:
{:type :required :keys [:foo :bar] :msg "blah"}
{:type :at-least :keys [:foo] :args [1]}
This could actually be added without breaking backwards compatibility. A multimethod could convert vector validations to hash map ones. It would be a bit hacky, but I think not breaking compatibility is important.
This has other benefits, like being able to style certain form fields according to their validations (asterisks next to required inputs, etc).
The text was updated successfully, but these errors were encountered: