UX Forms has an extremely flexible validation framework where each individual form control can have many constraints applied to it. Say you want a question to be mandatory but also have a minimum and maximum length? No problem, there’s a constraint for each of those already built-in and ready to use.
For example, this is what it looks like to declare a text field that is both mandatory and must be a number.
And this is what the form will look like when trying to Continue without entering anything:
But what if you don’t want to overwhelm the page with too much information at once? Given widgets can have any number of validation constraints on them, it’s unlikely that it would make sense to show 20 or more validation errors for a single field.
Before today, the answer was that you could write your own custom validation constraint that applied all the rules you wanted and returned a single error message as appropriate. But whilst writing your own gives you ultimate freedom to have it work exactly how you need, UX Forms is all about being the best of both worlds. It provides an extensive set of behaviours already built-in to the platform whilst also giving you the freedom to extend it above and beyond should you need to. So the more we can provide for you, the easier it is to focus on making the form good rather than just making it work.
Easily show only the first validation error
Today we‘re pleased to announce the release of a new constraint that can be used to wrap any number of other constraints and will report only the first validation failure. It’s called FirstOnly and can be used like this:
Now instead of reporting all of the validation errors the form will show only the first one that fails. In this case, that the field is required:
But then if you do give it a value, the next validation error is shown:
How to upgrade
To pick up this new constraint you’ll need to upgrade your form to use at least version 15.18.1 of our uxforms-dsl, either directly in your form’s build.sbt or instead by upgrading to at least version 2.5.1 of our sbt-formdefinition-plugin which can be found in project/formdef.sbt.
Should I show one or many validation errors?
We don’t know. Only you and your users can know that. Instead UX Forms gives you the tools to make the choices that are right for you, rather than the ones that are right for us.
After all, user needs should take priority over even the best-intentioned guidelines. If you can demonstrate that it is better to show all errors, then you should be able to show all errors. Likewise if evidence suggests that it is better to show only one, then you should be able to do just that. UX Forms’ built-in analytics dashboards can even tell you whether switching from one to the other has made things better or worse. Because whilst we love good intentions, we love backing them with data and evidence even more.
Want to know more?
Come have a look around https://uxforms.com, follow UX Forms on twitter, or email us at hello@uxforms.com and see how we can make your forms better, together.
