Marionette.jsMake your Backbone applications dance!

Who am ISenior 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

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

Why We Went BackboneFor Nulogy, we deal with huge amounts of

complicated business logic. Being able to evolve architecture without framework constraints is of very high value.

MarionetteTakes 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

Marionette Primitives

Marionette View MagicTakes care of rendering!

Takes care of template management

Provides UI object

Provides .close()

Extensibility points to allow customization of any piece of this

Automatic Render

UI Object

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

Model Events

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

CollectionViews

Marionette.CompositeViewCombination 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)

View ContainersWhich also manage memory

RegionSpecialized 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

LayoutA specialized item view which has multiple

regions

Great for a multi-view “widget”

Application Structure

Separating coordination code from computation code

ApplicationAn object to hold initialization and

bootstrapping logic

This is the only place I allow knowledge of the full page to live

ModuleLike an Application, but specialized for a

specific aspect of your code base

An Application is made up of many Modules

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

Application Level

Communication

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.

EventAggregatorBasically 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”)

CommandsA 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

Request/ResponseFor 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

Let’s Look at some code!