Flight @ scale

[Cameron Stitt]

I wanted people to bring forward any problems or solutions they have for assisting in making Flight easier to handle in a growing application. Flight by default makes scaling easy, but it is always good to share techniques we find helpful.

[Vsevolod Ivanov]

currently created http://tattooist.com (WARNING: russian interface only at the moment).

I have components folder, pages folder and layouts folder. every component\page\layout has 4 files, 1) with css (stylus) 2) with js (flight) 3) with template (currently handlebars, but we’ll move soon to custom solution) and 4) with test data (to run components without backend ready). So i can show every component (block of interface) separate.

I wrote parser, to parse templates to find partials, and build dependancy graph of components for pages, so i do component.attachTo manually only on global components (bound to document). That’s all, sorry for my runglish.

If i find time, i’ll open source my build tools and flow.

-- 
Vsevolod Ivanov
Sent with Airmail

[Dan Webb]

This sounds really interesting and quite along the lines of what we're considering for twitter.com.  Would love to know more.

--
Dan Webb / @danwrong

[Tom Ashworth]

A few of things off the top of my head that we do on Tweetdeck, where we have just under 200 Flight components forming about a third of the codebase (I think, rough calculations there!). This is how I think of it, at least. Others may disagree slightly, but there are the patterns I see in our code:

Components

- There are two, maybe three, discernable types of components: UI, UI controller and data.

- All three use mixins, although the sets of mixins they use do not tend to overlap.

- UI components are initialised around a specific, small area of DOM to add or create functionality there.

- We extensively use mixins with UI components to add functionality as diverse as templating, lifecycle management or opening dropdowns and modals.

- UI controllers and data components sit usually at the document level, but sometimes elsewhere.

- Data components rarely use mixins.

- UI controllers either tie together the functionality of a number of UI components or manage global state that a single component could not; the latter are often paired with a mixin. For example, we have a (very lightweight) DragDropController, and mixin called withDragDrop. These combine to allow any component to react to drag/drop behaviour – the controller just manages the start and end events that the individual components could not. Another example is the FocusController and withFocus.

- We nest components (!) using a mixin called withTeardown, which we really should open source or get into Flight core. It's very useful, allowing a component to attach a 'child' component and couple their lifecyles. Parent tears down; child tears down (but not the other way). 'Child' components can nest their own children, and so teardown can form a kind of cascade. This is really important for TweetDeck as it's a single page app – we can't (ever) teardownAll! Almost every new component we create uses it, and it (IMO) makes for some very nice code.

Events

- Events are namespaced by the type of component they come from (ui or data)

- These will (mostly) then be namespaced again according to what bit or functionality they are associated with: uiDragStart, uiKeyEnter, dataAuthComplete.

- There is also uiRequestX, but I haven't seen any new examples recently.

- We sometimes use xNeedsY for request/response-type event pairings: uiNeedsTypeaheadSuggestions and dataTypeaheadSuggestions.

- We try to trigger and listen on the document as infrequently as possible, preferring rather to trigger on the component's node and allow the event to bubble. This way you can reuse components in multiple contexts, with parent components managing those events however they see fit. It really works too – we reuse our login forms like this way.

Hope that helps. I think twitter.com have more sheer Flight code than us, but our lifecycle requirements are (afaik) completely different, so I'd imagine things are a bit different over there. Of course, this stuff is always evolving so I'd expect things to change.

Also, I'd be really interesting in comparing notes with others!

[Tom Hamshere]

Great to see some of these concepts being written down :)

I really like the idea of putting together a collection of Flight design patterns. Tom pointed me at a Backbone patterns collection: http://ricostacruz.com/backbone-patterns/

As an example of the controller/mixin pattern, I've just published a focus manager, flight-focus: https://github.com/tbrd/flight-focus

I'm also thinking of adding a mixin to https://github.com/tbrd/flight-keyboard-shortcuts to hide the events & remove bound shortcuts on teardown.

Tom, any chance you can show the core team the teardown code? I'm sure they'd be interested. Maybe open an issue on the flight repo?