Like anything, once you get a firm grasp of the overall framework the advanced operations kind of fall into place. There are useful resources out there written by developers in the community on advanced usage. That said, there were some pain points I encountered that made bridging the gap from rookie to novice a little challenging. With that in mind I set out to write up a sample app that would help me get over the hump. So for this entry I will dissect the included example and highlight the important stuff.
The apps purpose is simple - load a collection of items to an unordered list at run time and allow the users to add items of their own dynamically. All wired with click events to be toggled with a gray background to indicate selected and white background to indicate not selected.
NOTE: I suggest touring through the Fiddle a bit and understanding how things before continuing below. Loading it in another tab to flip back and forth to while continuing might also be beneficial.
Models
Model extensions are essentially representations of our data that we will be retrieving from our data tier and working with on the presentation layer. For this example we only have one model:
Item model - the Item model only has 2 properties (name and ordinal) and were are configuring their respective defaults. These will map seamlessly with a JSON data set, which we will see later.
Collections
Collections are, simply put, collections of Models.
ItemList - A basic instance of a collection that will contain Item models.
Views
Views are really what organizes and drives your interface; this is where you start modularizing everything. How you do this is entirely up to you, basically any element (be it the overall containing or any element somewhere in a list) on a page can be represented by a View. Once you work with Backbone a bit, you get a better feel for how to modularize your View logic.
ItemEntryView - This view will handle the user interactions with the textbox and "Add" button at the top of the page.
Notables:
el: Those familiar with jQuery the $(‘.itemEntry’) will look familiar. Here I am specifying the selector for the element (hence, el) on the page that an instance of ItemEntryView will control.
ItemView - This view will control any "Item" element that is added to the ItemsView.
Notables:
ItemList - A basic instance of a collection that will contain Item models.
Views
Views are really what organizes and drives your interface; this is where you start modularizing everything. How you do this is entirely up to you, basically any element (be it the overall containing or any element somewhere in a list) on a page can be represented by a View. Once you work with Backbone a bit, you get a better feel for how to modularize your View logic.
ItemEntryView - This view will handle the user interactions with the textbox and "Add" button at the top of the page.
Notables:
el: Those familiar with jQuery the $(‘.itemEntry’) will look familiar. Here I am specifying the selector for the element (hence, el) on the page that an instance of ItemEntryView will control.
ItemView - This view will control any "Item" element that is added to the ItemsView.
Notables:
- className: Kind of self explanatory; this is the CSS class that will be added to the element that contains the views contents. In this case it would be "item".
- tagName: Since this view is dynamically generated, you may want to specify what kind of element will contain the views contents. In this case, I have an li element specified so these views will be output as ‹li>. *content here* ‹/li>.
- events: The events array is a shorthand way to let you wire up events for the view. I only have one event setup for when the view is clicked it will call the "toggle" function. Simple as that and Backbone takes care of the rest.
When new views are added or updated after the initial page load, the events are attached to them (think jQuery live/delegate).
ItemsView - The view that will manage all of the ItemView instances added to the .items container.
Notables:
ItemsView - The view that will manage all of the ItemView instances added to the .items container.
Notables:
- collection: Here we are essentially specifying a collection that the ItemsView will “listen” to and give context to the view when collection is referenced in other methods.
- initialize: The constructor of a View that is called when a ItemsView is invoked. Just specifying the collection property will give you context, in order to stay in sync with the collection we bind any resets and adds to the collection with callbacks to the render and add methods, respectively. Simply put, any time a reset/add is called on the collection (outside of this view) the render/add method for this view will be called; that way the UI stays in sync with the data. This is where the meat and potatoes of Backbone really start to show themselves.
Conclusion
Still some confusion? Here's a visual:
Hopefully this mess all offers another helpful look at this framework and helps someone out looking to learn up on it. There is a lot of useful functionality in this library so I am still learning the ins and outs and working it into apps, when practical.P.S. While Backbone definitely helps alleviate a lot of typing, applications can still produce a significant amount of code. Managing that on an enterprise level would be a whole other post.
To help get an idea on how to properly arrange things I suggest taking a look at this tutorial.
