Crooked Grind BY MR IMAXX

Crooked forms

Reflexion on form validation improvement for AngularJS

Tommy Rochette
AngularJS Adventures
3 min readAug 1, 2013

--

Born way before fancy animations and cutting edge javascript frameworks, forms are one of the most commonly use element on the web. Still, in any programming language dealing with forms is complex and requires a lot of custom validation logic and special care for user experience.

Lately I was dealing with forms in an AngularJS project. Requirements were somewhat basic and contained a minimum of contextual validation. But with the current implementation of FormController and validation directives I ended up with dirty HTML templates and a lot of custom code for what I thought would be a chime to implement.

Actually, it’s not all bad, current implementation works fine and I saved a lot of time compared to developing a custom solution, but there is a few things that could be improve.

Form is only valid within a certain context

Cliff Meyer pointed to me an article written by Martin Fowler a couple years ago titled “Contextual Validation.” To make it short, you can take the exact same form, insert it in two different applications, and validation required will change drastically. It’s simple, form validity is deeply tie with business logic of the application they are living in.

Currently in AngularJS if we need a complex contextual validation we need to write a custom directive that will take care of this. This is good, not great. I would much prefer using models to encapsulate custom validation logic and exposing it through scope properties.

This could be simply done by adding a generic directive on input fields: ng-validate that would receive a function returning a boolean as a parameter. Contextual Validation made easy.

Contextually generated inputs

As a developer we often need to generate input fields dynamically since input validation is based on the current state of the form. Using FormController, new fields will be added to the validation process when they are generated.

However developers face multiple limitations with generated inputs. First, you can’t generate dynamic name for your input fields. We can solve this with predetermined names and templates. This take times and requires a lot of custom code. It would be handier to evaluate expression being passed in the name attribute instead.

Second, validation directives doesn’t listen $destroy event to cleanup form validation logic after an input is deleted. That means that if you remove a field in an invalid state, form will stay invalid forever.

Validation logic needs to be reusable on backend

With the rise of server side javascript solutions like Node.js, developers can’t afford code duplication on the client and the server. Business logic required the validate forms to be shared between these two.

AngularJS does not facilitate this approach as directives are deeply tied with DOM and Angular’s logic. Using the ng-validate approach pictured above, developers could easily create a validation class in native javascript that could be reused on the server side.

To push this further, we could also move all validation logic from AngularJS validation directives into Angular.validate module. Then we could easily share the exact same validation rules on the back end.

To sum up, next iteration of AngularJS forms should focus on providing developers a better toolset for contextual validation and more flexibility around dynamically generated input fields. As a bonus, it should expose validation logic locked in directive into models and allow developers to build on them.

AngularJS is an open-source JavaScript framework, maintained by Google, that assists with running single-page applications. Its goal is to augment browser-based applications with model–view–controller (MVC) capability, in an effort to make both development and testing easier.

--

--

Tommy Rochette
AngularJS Adventures

Architect at @universalmind. Mountain bike enthusiast and mobile addict.