English | 2013 | 244 Pages | PDF, EPUB | 10 MB
Backbone.js has become a popular library for developing modern web applications as their complexity and size increase. With Marionette.js, boilerplate code is handled by the library, letting you focus on your application’s specifics. You’ll discover Marionette components, along with when and why to use them. After you’ve made it through the book, you’ll be comfortable writing a Marionette application on your own.
Exercises covering the basic concepts are included (with solutions), so you can check for yourself if you’ve properly understood the functionality that was covered in a given chapter.
You’ll learn how to build the application at davidsulc step by step, including:
- Structuring your large apps with modules to manage complexity
- Using regions and layouts to segment your displays and make them manageable
- Managing forms, along with error display
- Handling data latency and displaying loading views
- Filtering collections and updating views, matching URL fragments to filtering criteria
- Extending the Marionette framework to clean up your code and make your life easier
- Using mixins to add common functionality to objects
- Defining your own view classes to extend from, sharing common behavior
- Implementing Backbone routing properly
- Swapping sub-applications
- Managing menu entries with non-persisted models
And much more! All of this is covered step by step so you fully understand how and why code is being added, removed, or refactored.
The ‘Header’ Sub-Application
We’re going to manage the menu in our header with a sub-application. It will control application switching, but will also track the currently active application so its menu entry can be highlighted. All of these features will be handled by manipulating Backbone models, and without nasty HTML data- attribute trickery. Instead, we’ll use the composite view you’ve come to know and love.
Setting up the Models
Our models will each represent one entry in our header menu, so we’ll need them to have name and url attributes to store the text we’ll display in the link and the link’s location, respectively. And in addition to these attributes, we’ll also need to determine the active menu entry so it can be highlighted:
To do so, we’ll use Derick Bailey’s Picky¹⁷⁰ Backbone plugin: it will allow us to select a certain item in the collection, and automatically deselect all the others. That’s exactly the behavior we want for our header, since only one entry can be active at any given time. Start by getting the backbone.picky plugin here¹⁷¹ and saving it in assets/js/vendor/backbone.picky.js. And we’ll need to include it in index.html to be able to use it:
We’re using an event listener instead ofa trigger object (see this exercise solution), because it allows us to prevent the event from bubbling up in the DOM and getting our row highlighted, as you may remember. In addition, we need to prevent the browser from navigating to the link’s location: when we click the link, the browser will by default navigate to that location. The problem is, we don’t want the browser navigating our app: when the user clicks the “show” link, the model gets displayed in a
dedicated view, and that’s it. So we prevent the link from leading our browser anywhere by calling preventDefault on line 13.
Our ContactManager app now lets users navigate from the contacts index to a page displaying a contact. But once the user gets to the contact’s page, he’s stuck: the browser’s “back” button doesn’t work. In addition, users can’t bookmark a contact’s display page: the URL saved by the browser would be the index page. Later, when the user loads the bookmark again, the user will end up seeing the contact list view instead of the contact’s display page he expected. To address these issues, we’ll
implement routing in our application.