1.2 Backbone Data Flow
Backbone applications depend very strongly on having a "single source of truth": this is the data that controls the state of the application. In this lesson, we'll look at exactly how this flow of data goes.
1.Getting Started3 lessons, 13:56
2.Backbone Models7 lessons, 38:03
3.Backbone Collections6 lessons, 17:52
4.Backbone Views4 lessons, 26:08
5.Backbone Routers3 lessons, 11:19
6.Conclusion1 lesson, 01:36
1.2 Backbone Data Flow
Before we look at the actual components of Backbone, I want to talk for a second about the way that data flows through a Backbone application. I find it helpful to think about Backbone applications as being data driven. All the data that you work with in your application will probably be in the form of Backbone models and Backbone collections. These are the containers that Backbone gives you to manage your data. And as we'll see, these containers are responsible for doing validation, holding business logic, maybe converting data, really anything that applies to the data of the application. Models give you the ability to listen for any changes to given fields of data and update the interface when the model's attributes change. And then the collections are exactly that, groups of models. Usually, you'll have many instances of a model. So for example, you might have many documents or many messages, or images, or questions, or contacts, or episodes, or whatever your core unit of data, if you will, is. So you store each of these models inside a collection, and you may want to render them as a group. So you can watch a collection for changes as well so that you can update, say, a list interface when items are added or removed from a collection. The collections and models also have the connection between the server and the client. Usually this will be part of the collection. It will have access to the server API where it can create new models, update existing models, destroy models and of course, read them as well. So that is kind of the data portion of your Backbone application. But then as I already mentioned, you'll have your interface which of course, is made up of views which will of course, display the data and most likely give the user the ability to change the dataset in some way. For example, adding, removing or changing models. The views of course, will then change the models in collection to it which can in turn save those changes and then update other views with those changes. Right here you can see I've built a very simple example of this. If you look at the code that I'm loading over here on the right hand side, you can see right here we create our model. It's a book and it has two properties, a title and an author. So this is our data source, if you will. Now we have two views, the BookView and the BookEditView, which are these two portions you see over here. The headers are of course, the book view and then of course, these text inputs are the edit view. So these are two views that we're using both to render the very same model. And we'll look at the details of how this works throughout the course. Of course, the implementation of these views and model are written above the instantiation down here. Now the point of this sample application here is that the view that's displaying these text inputs is listening for changes to these and it will go ahead and update the actual model when we change the values in these text areas. Then the other view that we have up above here displaying this data is listening for those change events. And when the values change it will go ahead and update accordingly. So I can backspace all these letters as you can see, and it will clean up the title. And I can replace that with a new title, and then I can go ahead and change the author as well. And you can see that as I type each character, their corresponding events are triggering right away and we see the update. So that is a quick example of the data flow in your typical Backbone application, and we'll see more of this as we work throughout these lessons.