I’m going to discuss how I went about learning Backbone.Marionette.
Backbone.Marionette is the combination of:
Backbone.Marionette is the combination of:
- Looking to build complex larger-scale, rich client web apps.
- Heard about various advantages
- reduce boilerplate code
- memory management/cleanup strategies
- comes with it’s own developer philosophy helps structure your application code
MethodI went about learning marionette by taking an existing backbone application that I had worked on and introduced marionette to it
- Created new application and router
- The Application is a component of the mvc framework that organizes, initializes and coordinates the various pieces of your app.
- A Router’s job is boiled down to 2 things: execute controller actions corresponding to the URL that the user first “entered” our Marionette app with. It also updates the URL as the user navigates the application
- Looked for patterns/abstractions in Marionette that we could use in our current backbone views (Just as a side note I never looked at doing anything with the Models)
Some of the things I learned
CompositeViewTo begin with I looked for patterns/abstractions in Marionette we could use in our current views. One of those views is shown below:
Here we have the template of one of the pages of the application I’m introducing Marionette to. Now if we gloss over the design/UI aspect of the page and focus on the structure what we can see is that it’s rather quite simple. All this page is doing is displaying a collection within a wrapper template. The collection being the areas highlighted in green - what we call “Spokes”.
Now if we focus in on the spokes we can see that the same concept applies, it’s just a collection being rendered inside a wrapper template.
All we’re displaying in these 2 views is displaying a collection inside a wrapper template... A perfect use case for CompositeView, from the docs, which I might add are a fantastic resource.
So by replacing the relevant Backbone.Views with Marionette.CompositeView I was able to remove the following boilerplate code:
On render we’re iterating over the collection of spokes passing each spoke into the addOne function. The addOne function we’re instantiating a new spoke view, calling render and appending to the DOM element we want to show our spokes in.
By using CompositeView it now looks like:
- itemView: the view each item in collection will be used in
- itemViewContainer: defines DOM element that our collection will be displayed in
- initialize: set the collection
TriggerMethodAnother good feature of using CompositeView is event handling between parent and child views.
If an event is triggered from a child view then that event gets bubbled up to the CompositeView prefixed with the string “itemview”.
If we take the following code:
Here we have a view that has an event handler for the click event called “spokeClicked” which in turn triggers an event “spoke:click”.
On the parent the code for handling the event on the child view looks like this:
Since the event that gets bubbled up to the parent CompositeView is called “itemview:spoke:click” then the corresponding method that will be called is “onItemviewSpokeClick”
Again saves us from having to define an event listener, removing boilerplate code. This Marionette pattern is known as TriggerMethod.
Marionette.ModuleI like to think of modules as an encapsulation of everything necessary to execute one aspect of the desired functionality. Allows you to group all parts involved in the execution of that piece of functionality in a logical structure.
Unfortunately Backbone.js does not tell you how to organize your code, leaving many developers in the dark regarding how to load scripts and lay out their development environments.
Marionette comes with its own implementation of how to construct modules. Marionette promotes the development philosophy of modularization of code through its Module library.
As well as promoting modular structure to your applications it also has the ability to stop/start modules to clear memory and resources when the module is no longer required.
ResultsThe whole point of this exercise was to begin an introduction into Marionette. As a training exercise, yes was worthwhile. Found it great for learning some of the features of marionette. It was a problem that I’ve already solved so finding patterns was fairly easy. Less focus on understanding problem and more on applying functionality of marionette.
In terms of reducing boilerplate code the effect was fairly minimal did reduce code but was only about 15 lines from a possible 264. The application used was probably too simple to utilise and learn more of the Marionette functionality
I think I saw enough and got a good taste for Marionette that if and when we do begin to create more complex, rich-client interfaces then I’d be interested in using Marionette.