Intro to marionetteJS talk

1. Marionette.js
Make your Backbone applications dance!

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. 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. 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. 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. Marionette
Primitives

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. Automatic Render

9. UI Object

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. Model Events

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. CollectionViews

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. View Containers
Which also manage memory

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. Layout
 A specialized item view which has multiple
regions
 Great for a multi-view “widget”

18. Application
Structure
Separating coordination code from
computation code

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. Module
 Like an Application, but specialized for a specific
aspect of your code base
 An Application is made up of many Modules

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. Application
Level
Communication

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. 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. 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. 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. Let’s Look at
some code!