Building a JavaScript Module Framework at Gilt

  • 8,310 views
Uploaded 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 …

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.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • 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.
    Are you sure you want to
    Your message goes here
  • I might not be understanding your question correctly, but look at slide 41 for the actual instantiation of a module.
    Are you sure you want to
    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?
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
8,310
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
100
Comments
3
Likes
25

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Building a JavaScriptModule Framework at Gilt Eric Shepherd @arkitrave
  • 2. Whois?‣ background ‣ music | architecture | web design | front end engineering‣ companies ‣ fisher-price | condé nast | gilt groupe
  • 3. Thank You!‣ Nicholas Zakas ‣ scalable javascript application architecture presentation‣ jQuery Conference 2010 ‣ presentations on pubsub, templating, yepnope, and js architecture
  • 4. Why?
  • 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
  • 9. Demands
  • 10. Demands‣ allows multiple unique module instances
  • 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
  • 14. Components
  • 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
  • 19. Architecture
  • 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. Architecture
  • 22. Gilt.App
  • 23. Gilt.App
  • 24. Architecture
  • 25. Gilt.Sandbox
  • 26. Gilt.Sandbox
  • 27. Architecture
  • 28. Module
  • 29. Module
  • 30. Module View (opt.)
  • 31. Module View (opt.)
  • 32. Architecture
  • 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. Architecture
  • 35. Wiring It Up‣ on your own site ‣ page controller‣ on a third-party site ‣ bootstrap as js loader and controller
  • 36. WTF
  • 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. A Better Bootstrap
  • 39. …Which Returns…
  • 40. Server-Generated Closure
  • 41. Yep. Nope.
  • 42. Watch Out For…
  • 43. Watch Out For…‣ make sure your bootstrap is RESTful
  • 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