Building a JavaScript Module Framework
at Gilt
Eric Shepherd@arkitrave
Whois?
‣ background‣ music | architecture |
web design | front end engineering‣ companies‣ fisher-price | condé nast | gilt groupe
Thank You!
‣ Nicholas Zakas‣ scalable javascript application
architecture presentation‣ jQuery Conference 2010‣ presentations on pubsub, templating,
yepnope, and js architecture
Why?
Why?
‣ code organization‣ small files + objects, each with a
defined role
Why?
‣ code organization‣ reduce points of dependency‣ modules communicate through only
one channel
Why?
‣ code organization‣ reduce points of dependency‣ unobtrusiveness for third-parties‣ other sites can include your code
without fear
Why?‣ code organization‣ reduce points of dependency‣ unobtrusiveness for third-parties‣ adaptability + extensibility‣ any piece of the application can be
switched out without affecting the rest of the application
Demands
Demands
‣ allows multiple unique module instances
Demands
‣ allows multiple unique module instances
‣ does not allow modules to talk to each other‣ freedom in clear boundaries
Demands‣ allows multiple unique module
instances‣ does not allow modules to talk to
each other‣ tightly restricts dom access (with a
few exceptions)‣ the page doesn’t need to worry
about being messed with
Demands‣ allows multiple unique module
instances‣ does not allow modules to talk to
each other‣ tightly restricts dom access (with a
few exceptions)‣ touches as little global code as
possible‣ ideally, only one global var
Components
Components
‣ Gilt.App‣ there is only one‣ manages all modules, provides one
sandbox to each module ‣ public api is register(), start(), stop(),
startAll(), stopAll(), view.register()
Components
‣ Gilt.App‣ Gilt.Sandbox‣ instantiable, one instance per module‣ provides pubsub, state management,
dom interaction, services, views
Components‣ Gilt.App‣ Gilt.Sandbox‣ module itself‣ implements a simple create() and
destroy() interface‣ it’s an overprotected child, with a
limited view of the world
Components
‣ Gilt.App‣ Gilt.Sandbox‣ module itself‣ …along with core code and helpers
Architecture
Flow‣ a module is a function, passed to
App.register() as a creator‣ on App.start(), a new Sandbox()
instance is passed to that creator, which returns public create and destroy methods, and…
‣ the new module instance’s create() is called
Architecture
Gilt.App
Gilt.App
Architecture
Gilt.Sandbox
Gilt.Sandbox
Architecture
Module
Module
Module View (opt.)
Module View (opt.)
Architecture
The Hoff Helpers‣ jQuery‣ underscore.js‣ handlebars.js‣ yepnope.js‣ &c…but modules can’t know
anything about these (jQuery as a partial exception due to its plugin architecture)
Architecture
Wiring It Up
‣ on your own site‣ page controller
‣ on a third-party site‣ bootstrap as js loader and controller
WTF
A Better Bootstrap
‣ don’t be a jerk – think of the children‣ protect the global scope – you’re in
someone else’s house!‣ make it easy to inline or inject the
script dynamically‣ keep the payload light – it’s like
spending someone else’s money
A Better Bootstrap
…Which Returns…
Server-GeneratedClosure
Yep. Nope.
Watch Out For…
Watch Out For…
‣ make sure your bootstrap is RESTful
Watch Out For…‣ make sure your bootstrap is RESTful‣ css‣ conflicts are a bitch‣ and you can’t use id selectors‣ !important is your only hope‣ jquery.important can help, but it’s the
roach motel, and animations are out
Watch Out For…
‣ make sure your bootstrap is RESTful‣ css‣ jQuery‣ plugin convention requires a globally-
accessible jQuery object‣ so noConflict(true) will work only if
you don’t need plugins‣ use sandbox.getContainer().find()
Watch Out For…
‣ make sure your bootstrap is RESTful‣ css‣ jQuery‣ cross-domain issues‣ make sure your feeds are jsonp
Watch Out For…‣ make sure your bootstrap is RESTful‣ css‣ jQuery‣ cross-domain issues‣ assumptions of shared code‣ included code can later introduce
dependencies unavailable on a third-party site, hard to test
You Can Do Anything
‣ anything at all‣ the only limit is yourself‣ …yes…
