Taking Flight

An overview of the Flight framework by Twitter

I first tried Flight in March this year when I created a simple Todo app. After completing that, I didn’t look at Flight again until a month ago. I started using it for a personal project and after a few initial struggles I feel like it could be the long-term framework I have been looking for. The reason for this is summed up nicely on the Flight website:

It’s agnostic to how requests are routed, which templating language you use or even if you render your HTML on the client or the server.

Lift Off

Getting Flight set-up was easy. Using Bower, I installed the known requirements (es5-shim, jQuery, requirejs) and setup my first component.

define(function(require) {
  var defineComponent = require(“flight/lib/component”);
  return defineComponent(helloWorld);
  
  function helloWorld () {
    this.after("initialize", function() {
      alert("Hello World!");
    });
  }
});

Pretty simple, isn’t it. This is doing nothing more than using Flight’s Advice API to wrap the default “initialize” method and alert them once it’s ready. For this to run, you need to attach the component to the page.

require(["ui/helloWorld.js"], function(HelloWorldUI) {
  HelloWorldUI.attachTo(document);
});

Again, pretty simple. The attachTo method accepts a DOM element which becomes the context for the component.

Where Are My Models?

Flight does not handle models directly. The following is a quote from the Flight website:

It doesn’t prescribe or provide any particular approach to rendering or providing data to a web application

This means it is up the developer to choose the best approach for each application. Some approaches I have seen mentioned in regards to Flight are:

• No models (Objects and arrays. Wow!)
• laces.js

At this point I am leaning towards the modeless approach. Libraries such as Lodash provide enough utilities to make working with arrays and objects more than bearable. Some Mixins could easily be created to help manage anything that seems to be repeating. What is a mixin you ask? Great question.

Mixins

Mixins are the most powerful feature of Flight. They are plug and play scripts that help keep your code DRY. Mixins can be applied to both components or standard objects. Here is an example of a simple request Mixin that helps handle ajax. This can then be applied to a component like so:

var withRequests = require("mixins/withRequests");
return defineComponent(helloWorld, withRequests);
function helloWorld() {
  this.after("initialize", function() {
    this.post(...);
  };
}

Folder Structure

The standard folder structure consists of the following:

• ui — Files that handle DOM interaction
• data — Files that handle data (eg. perform requests, filtering)
• mixins — Mixins, obviously

Event Naming

I recommend using TweetDeck’s guide to event naming in Flight. The three below are the ones I most commonly use:

• UI data request — uiNeedsUsers
• UI request — uiRemoveUser, uiShowUsers
• Data event (usually a flow-on from a UI data request) — dataUserProfile

A quick example of how these could work can be found here.

Smooth Landing

Although Flight is not gaining the same amount of traction as Backbone.js or AngularJS, it is a more than worthy competitor. Although it does not provide Model-view-controller functionality out of the box, the developer has full control over how data will be managed, how rendering will be performed and so on. If you’re interested, head on over to the Flight website and try it out.