For modules to function within a large-scale system and on third-party sites, they need to be self-contained units with minimal dependencies. They also need to keep their hands off of other modules and library code. Gilt's module framework manages multiple independent components, providing them with what they need, and only what they need, to do their jobs.
5. Why?
‣ code organization
‣ small files + objects, each with a
defined role
6. Why?
‣ code organization
‣ reduce points of dependency
‣ modules communicate through only
one channel
7. Why?
‣ code organization
‣ reduce points of dependency
‣ unobtrusiveness for third-parties
‣ other sites can include your code
without fear
8. 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
11. Demands
‣ allows multiple unique module
instances
‣ does not allow modules to talk to
each other
‣ freedom in clear boundaries
12. 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
13. 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
15. 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()
16. Components
‣ Gilt.App
‣ Gilt.Sandbox
‣ instantiable, one instance per module
‣ provides pubsub, state management,
dom interaction, services, views
17. 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
18. Components
‣ Gilt.App
‣ Gilt.Sandbox
‣ module itself
‣ …along with core code and helpers
20. 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
33. 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)
37. 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
44. 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
45. 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()
46. Watch Out For…
‣ make sure your bootstrap is RESTful
‣ css
‣ jQuery
‣ cross-domain issues
‣ make sure your feeds are jsonp
47. 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
48. You Can Do Anything
‣ anything at all
‣ the only limit is yourself
‣ …yes…
49. Questions?
‣ Eric Shepherd
‣ eric@arkitrave.com
‣ @arkitrave