Building a JavaScript Module Framework at Gilt

10,304 views

Published on

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.

Published in: Technology
3 Comments
26 Likes
Statistics
Notes
  • In response to a couple of email questions.

    First, a question about the Sandbox API:

    The sandbox does not need to provide implementations directly for everything; in fact, that's a bad idea because the sandbox JS will just keep getting larger and larger.

    In Gilt's framework, the sandbox provides a specific pubsub interface because it prepends the module's ID and makes it easy for modules to publish and subscribe. However, it doesn't provide a query engine or DOM access. Rather, it looks for services like these in the options object that's passed into it at instantiation, allowing these services to be injected. In much of the Park & Bond site code, we use jQuery, and pass it into each module when created. In another project I'm currently working on, I'm using microlibs and passing those in instead of jQuery.

    So all code that is used by a module will be accessed through its sandbox, but most of it will simply be passed through rather than coded or specified in the sandbox.js file.

    Second, a question about views:

    Views seem to be working out well the way I wrote them; at the time of this presentation I hadn't actually implemented modules with separate views in this framework. However, in the Park & Bond site there are modules which can have different views depending on where it is on the site. The ajax calls and business logic is in the module, and the DOM manipulation and subscriptions to the module events are in the views.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • I might not be understanding your question correctly, but look at slide 41 for the actual instantiation of a module.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Thanks for the slides; they rock! I have no problem defining modules and their own sandboxes. However, what does it look like when you start from scratch and want to kick off a new App with Sandbox?
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
10,304
On SlideShare
0
From Embeds
0
Number of Embeds
1,742
Actions
Shares
0
Downloads
113
Comments
3
Likes
26
Embeds 0
No embeds

No notes for slide

Building a JavaScript Module Framework at Gilt

  1. 1. Building a JavaScriptModule Framework at Gilt Eric Shepherd @arkitrave
  2. 2. Whois?‣ background ‣ music | architecture | web design | front end engineering‣ companies ‣ fisher-price | condé nast | gilt groupe
  3. 3. Thank You!‣ Nicholas Zakas ‣ scalable javascript application architecture presentation‣ jQuery Conference 2010 ‣ presentations on pubsub, templating, yepnope, and js architecture
  4. 4. Why?
  5. 5. Why?‣ code organization ‣ small files + objects, each with a defined role
  6. 6. Why?‣ code organization‣ reduce points of dependency ‣ modules communicate through only one channel
  7. 7. Why?‣ code organization‣ reduce points of dependency‣ unobtrusiveness for third-parties ‣ other sites can include your code without fear
  8. 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
  9. 9. Demands
  10. 10. Demands‣ allows multiple unique module instances
  11. 11. Demands‣ allows multiple unique module instances‣ does not allow modules to talk to each other ‣ freedom in clear boundaries
  12. 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. 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
  14. 14. Components
  15. 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. 16. Components‣ Gilt.App‣ Gilt.Sandbox ‣ instantiable, one instance per module ‣ provides pubsub, state management, dom interaction, services, views
  17. 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. 18. Components‣ Gilt.App‣ Gilt.Sandbox‣ module itself‣ …along with core code and helpers
  19. 19. Architecture
  20. 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
  21. 21. Architecture
  22. 22. Gilt.App
  23. 23. Gilt.App
  24. 24. Architecture
  25. 25. Gilt.Sandbox
  26. 26. Gilt.Sandbox
  27. 27. Architecture
  28. 28. Module
  29. 29. Module
  30. 30. Module View (opt.)
  31. 31. Module View (opt.)
  32. 32. Architecture
  33. 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)
  34. 34. Architecture
  35. 35. Wiring It Up‣ on your own site ‣ page controller‣ on a third-party site ‣ bootstrap as js loader and controller
  36. 36. WTF
  37. 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
  38. 38. A Better Bootstrap
  39. 39. …Which Returns…
  40. 40. Server-Generated Closure
  41. 41. Yep. Nope.
  42. 42. Watch Out For…
  43. 43. Watch Out For…‣ make sure your bootstrap is RESTful
  44. 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. 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. 46. Watch Out For…‣ make sure your bootstrap is RESTful‣ css‣ jQuery‣ cross-domain issues ‣ make sure your feeds are jsonp
  47. 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. 48. You Can Do Anything‣ anything at all‣ the only limit is yourself‣ …yes…
  49. 49. Questions?‣ Eric Shepherd‣ eric@arkitrave.com‣ @arkitrave

×