Posted on by & filed under Content - Highlights and Reviews, Programming & Development.

A guest post by Scott Rabin, a Front End Technical Lead for Huddler, Inc., a forum platform and media company. When he’s not working on bringing communities together, he’s working on Javascript utility libraries and web-based home theater software.

Flight is a component-based Web framework from Twitter that helps you write modular code and assemble these pieces into a fully-featured application. Components can range from small, generalized pieces of functionality like a custom dropdown menu, to larger, specialized workflows like viewing a paginated set of comments. Separating your application into its fundamental components is often the first step in writing a web application with Flight.

In this post, we will be constructing a form validation component to provide users feedback when specific form fields contain invalid values. Though many form fields can be fully validated by a combination of constraints from the HTML5 Constraints API, some fields have specific validation rules that need a more direct approach. Our form validation component will use a combination of the Constraints API custom validity functionality and Flight to make writing custom form validation rules simple.

A Concrete Example

Developing our validation component against a real form can help us describe the functionality we need. We’ll use a common form found all over the web – the User Registration form.


Three simple fields (and one to double-check) are all we need to describe a unique user on a site. We’ll want to make sure all of our users have unique username, so we’ll need to check the server each time a user enters a new username. We’ll also want to prevent users from signing up twice with the same email address, so we’ll need to check with the server for the email field, too. The password field can be easily validated with the Constraints API, but the “Confirm Password” field needs to reference the “Password” field and will need a custom validator.

The Markup

We don’t want to re-invent the wheel with our validation component and describe each field in every form on our site, so we should try to use as much of the native validation machinery as possible. We’ll just need to create attachment points for our custom validators to use in addition to the markup-based validation:

The Form Component

We’ll write our user registration form component in an idealized way to see how we want to express our validation. The best-case scenario is a map of fields to validation functions, so let’s write that out and see if we’ve missed anything:

Since we’ll want to be able to easily define custom validation functions for many forms on our site, we’ll want to encapsulate all of the relevant logic in a mixin that implements the validation machinery and leave the custom definitions in the implementing component. With regards to validators, our two “unique” fields (username and email) need to make an asynchronous call to the server to validate; we’ll assume a function checkUnique exists that returns a promise and eventually resolves it with a falsy value (“”, false, or null)  if the field is valid or an error message to display to the user (like “That username is already taken”). For the password field, we’ll leverage the pattern attribute and provide some basic requirements for at least one capital letter, at least one number, and at minimum 8 characters, and we won’t define a custom validator. The password confirm field, however, will need to be checked when it is changed.

The Validation Mixin

This implementation shows us the basic API our validation mixin will need to be useful – the setValidators function. It should accept a map of selector name to the relevant validation function and provide the rest of the needed machinery. Specifically, it should bind the necessary callbacks to validate each field as the user types, and be able to handle promise, string, and falsy return values. It should also work as expected with the “password” field, which doesn’t have a custom validator attached. Lastly, when a field is found to be invalid, it should apply the class has-error to the containing field group element so we can style it:

The implementation of setValidators is fairly straightforward; loop over the given validation map, wrap each validation function to normalize the return value into a promise and then set the custom validity message on the element with the value of the normalized promise. The uiNeedsValidation event, however, is not as obvious. In order for our validator to work with native constraints, we need a way to funnel the input events from those elements into the same code path as the custom validators to apply the has-error class to the container. Separating the source event from the work function promotes this sort of code, where multiple disjoint event sources can flow through the same sequence of functions to achieve a consistent result. You can learn more about this approach in Chapter 4: Triggering and Responding to Events in The Twitter Flight Edge. In the mean time, let’s take a look at our handiwork (using some dummy functions for the username/email validation):


Not bad for ~80 lines of Flight-based Javascript! Of course, this leans heavily on the browser for managing the form submission and displaying the error message, but we’ve encapsulated all of the validation display logic into our ValidationMixin, such that switching to a more general purpose or cross-browser library should be fairly trivial and shouldn’t affect our existing form component implementations. Mixins are one of the more powerful features in Flight and, when used properly, can dramatically tighten code and offer convenient ways for multiple components to behave consistently across your site.

Extending the Validation Mixin

We’ve built a fairly general component to define custom validation functions on a per form basis, but there’s plenty more functionality we can get from our mixin while still presenting the same interface to implementing components. Here’s a few ideas to get you started:

  • Revalidate the “Confirm Password” field when the original password field is changed
  • Display the error message for each field in red text underneath the element
  • Allow a custom error message to be defined on each element

Not a subscriber? Sign up for a free trial.

Be sure to look at the Twitter Flight and JavaScript resources that you can find in Safari Books Online.

Safari Books Online has the content you need

The Twitter Flight Edge covers the open source library from Twitter used heavily in their front end JavaScript. It offers a lightweight way to define the behavior of and communication between components, which are well-defined fragments of a page meant for progressive enhancement. This book was written for the curious JavaScript developer who learns new libraries by hacking on examples or personal projects. We walk through developing a simple sample application – an RSS reader – using Twitter Flight and supporting libraries. Everything from basic components like tabs to remote data fetching is covered, highlighting the benefits Flight offers for event-driven applications.
Eloquent JavaScript is a guide to JavaScript that focuses on good programming techniques rather than offering a mish-mash of cut-and-paste effects. The author teaches you how to leverage JavaScript’s grace and precision to write real browser-based applications. The book begins with the fundamentals of programming—variables, control structures, functions, and data structures—then moves on to more complex topics, like object-oriented programming, regular expressions, and browser events. With clear examples and a focus on elegance, Eloquent JavaScript will have you fluent in the language of the web in no time.
Maintainable JavaScript contains JavaScript practices—including code style, programming tips, and automation—and you’ll learn how to write maintainable code that other team members can easily understand, adapt, and extend. Author Nicholas Zakas assembled this collection of best practices as a front-end tech leader at Yahoo!, after completing his own journey from solo hacker to team player.

About the author

scottrabin Scott Rabin is a Front End Technical Lead for Huddler, Inc., a forum platform and media company. When he’s not working on bringing communities together, he’s working on Javascript utility libraries and web-based home theater software, and can be reached at

Tags: Constraints, Constraints API, Flight, html 5, mixins, Scott Rabin, twitter, Twitter Flight, User Registration Form,

Comments are closed.