Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Marionette.js
Make your Backbone applications dance!
Who am I
 Senior front end dev at Nulogy (we are hiring!)
 Email - matt@mattbriggs.net
 Tweeter - @googleninja
 Coding...
Evaluating Frameworks
Without Bias
 The power of backbone is its flexibility and simplicity
 It is incredibly easy to en...
Why We Went Backbone
 For Nulogy, we deal with huge amounts of
complicated business logic. Being able to evolve
architect...
Marionette
 Takes the ideas of backbone a few steps further
 Still very simple
 Gives you primitives for building large...
Marionette
Primitives
Marionette View Magic
 Takes care of rendering!
 Takes care of template management
 Provides UI object
 Provides .clos...
Automatic Render
UI Object
Marionette.ItemView
 A view which is rendered based on model data
 “model” is your model
 “template” is a way to refere...
Model Events
Marionette.CollectionView
 View which renders based on a Collection
 Will automatically rerender on
add/remove/reset/etc...
CollectionViews
Marionette.CompositeView
 Combination of an ItemView and a
CollctionView (has both a model and a
collection)
 Great for ...
View Containers
Which also manage memory
Region
 Specialized view that holds other views
 Takes a view instance, calls render on it, and
adds it to the DOM
 The...
Layout
 A specialized item view which has multiple
regions
 Great for a multi-view “widget”
Application
Structure
Separating coordination code from
computation code
Application
 An object to hold initialization and bootstrapping
logic
 This is the only place I allow knowledge of the f...
Module
 Like an Application, but specialized for a specific
aspect of your code base
 An Application is made up of many ...
Controller
 Mediate complex interaction between
components
 Useful when you start having a fair amount of
coordination l...
Application
Level
Communication
ZOMG EVENTS!!
 In my experience, this is the most controversial
part of marionette
 Do not go down this road unless you ...
EventAggregator
 Basically the same thing as EventEmitter in node
 You can trigger events
 You can bind to events
 Use...
Commands
 A command is something which could be
triggered from multiple parts of the application,
but handled in a single...
Request/Response
 For when you want to provide some “Application
Level” data (for example, the current state of the
shopp...
Let’s Look at
some code!
Upcoming SlideShare
Loading in …5
×

Marionette - TorontoJS

2,575 views

Published on

Intro to marionetteJS talk

Published in: Technology
  • Be the first to comment

Marionette - TorontoJS

  1. 1. Marionette.js Make your Backbone applications dance!
  2. 2. Who am I  Senior front end dev at Nulogy (we are hiring!)  Email - matt@mattbriggs.net  Tweeter - @googleninja  Coding – http://github.com/mbriggs  Slides – http://slideshare.net/matt-briggs  Infrequently updated blog – http://mattbriggs.net
  3. 3. Evaluating Frameworks Without Bias  The power of backbone is its flexibility and simplicity  It is incredibly easy to end up in a bad place  If simplicity and flexibility are priorities, Backbone should be considered  All JS frameworks (like anything else in software) have both strengths and weaknesses  They are all great choices for very different reasons  Choose the right tool for the job
  4. 4. Why We Went Backbone  For Nulogy, we deal with huge amounts of complicated business logic. Being able to evolve architecture without framework constraints is of very high value.
  5. 5. Marionette  Takes the ideas of backbone a few steps further  Still very simple  Gives you primitives for building larger scale applications  Introduces some conventions to allow the removal of boilerplate  Introduces some ideas around building larger applications
  6. 6. Marionette Primitives
  7. 7. Marionette View Magic  Takes care of rendering!  Takes care of template management  Provides UI object  Provides .close()  Extensibility points to allow customization of any piece of this
  8. 8. Automatic Render
  9. 9. UI Object
  10. 10. Marionette.ItemView  A view which is rendered based on model data  “model” is your model  “template” is a way to reference your template  No render required!  modelEvents – bind to view methods when events fire on model
  11. 11. Model Events
  12. 12. Marionette.CollectionView  View which renders based on a Collection  Will automatically rerender on add/remove/reset/etc  Provide an itemView, which will get instantiated automatically, and given a model
  13. 13. CollectionViews
  14. 14. Marionette.CompositeView  Combination of an ItemView and a CollctionView (has both a model and a collection)  Great for master/detail  Useful for when a collection view is not enough (like when rendering a table)
  15. 15. View Containers Which also manage memory
  16. 16. Region  Specialized view that holds other views  Takes a view instance, calls render on it, and adds it to the DOM  The “bridge” between the DOM and the land of backbone
  17. 17. Layout  A specialized item view which has multiple regions  Great for a multi-view “widget”
  18. 18. Application Structure Separating coordination code from computation code
  19. 19. Application  An object to hold initialization and bootstrapping logic  This is the only place I allow knowledge of the full page to live
  20. 20. Module  Like an Application, but specialized for a specific aspect of your code base  An Application is made up of many Modules
  21. 21. Controller  Mediate complex interaction between components  Useful when you start having a fair amount of coordination logic building up somewhere – break it out into a controller!  Do not think about it in the MVC sense of the word, more as a Use Case Controller.
  22. 22. Application Level Communication
  23. 23. ZOMG EVENTS!!  In my experience, this is the most controversial part of marionette  Do not go down this road unless you are reasonably sure it is the right one to go down. Abuse of eventing will lead to unreadable code.  Application level events are very close to global function calls, keep that in mind.  The different types of events are there to provide additional semantic meaning to what kind of an event It actually is.
  24. 24. EventAggregator  Basically the same thing as EventEmitter in node  You can trigger events  You can bind to events  Use these for when you just want to notify the world of something happening, and multiple parts of the application may want to respond (ie: “user:logged-in”)
  25. 25. Commands  A command is something which could be triggered from multiple parts of the application, but handled in a single place.  Example: You can save by  cmd-s  Clicking a toolbar button  Choosing File => Save from the menubar
  26. 26. Request/Response  For when you want to provide some “Application Level” data (for example, the current state of the shopping cart)  Great for “global state” without having to pass around a mess of objects all over the place  Easy to abuse – a method call against a concrete object will always be more clear, and once something is globally available, it is hard to predict the impact of it changing
  27. 27. Let’s Look at some code!

×