Flight is distinct from existing frameworks in that it doesn't prescribe or provide any particular approach to rendering or providing data to a web application. 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. While some web frameworks encourage developers to arrange their code around a prescribed model layer, Flight is organized around the existing DOM model with functionality mapped directly to DOM nodes.
Not only does this obviate the need for additional data structures that will inevitably influence the broader architecture, but by mapping our functionality directly onto the native web we get to take advantage of native features. For example, we get custom event propagation for free by piggy-backing off DOM event bubbling, and our event handling infrastructure works equally well with both native and custom events.
How does it work?
Flight enforces strict separation of concerns. When you create a component you don't get a handle to it. Consequently, components cannot be referenced by other components and cannot become properties of the global object tree. This is by design. Components do not engage each other directly; instead, they broadcast their actions as events which are subscribed to by other components.
Events are open ended. When a component triggers an event it has no knowledge of how its request will be satisfied or by whom. This enforced decoupling of functionality allows the engineer to consider each component in isolation rather than having to reason about the growing complexity of the application as a whole.
By making DOM node events proxies for component events, we let the web work for us:
- we get event propagation for free
- a component can subscribe to a given event type at the document level or it can choose to listen only those events originating from within a specified DOM Node
- subscribing components do not distinguish between custom events from other components (e.g.
dataMailItemsServed) and native DOM node events (e.g.
click), and process both types of event in an identical fashion
Mobility and Testing
Each component is a module, which aside from a minimal set of standard dependencies (relevant Flight utilities and mixins), has no reference to the outside world. Thus a given component will respond to a given event in the same way, regardless of environment. This makes testing both simple and reliable — events are essentially the only variable and a production event is easy to replicate in testing. You can even debug a component by triggering events in the console.
Documentation and Demo
Flight is an ongoing project. We’re planning to add a full testing framework as well as making available more of the utilities that we use for the Twitter website frontend. We also look forward to your contributions and comments. We know we haven’t thought of everything and with your help we can continue to improve Flight for the benefit of everyone.
Flight was a group effort.The following folks contributed to the project: Angus Croll (@angustweets), Dan Webb (@danwrong), Kenneth Kufluk (@kpk) and the members of the Twitter web team.
On behalf of the Web Core team,
—Angus Croll, Engineer (@angustweets)