Backbone Reactive – Introducing the Dashboard

This is Part Five of the Backbone Reactive Tutorial. For all sections, please view the Table of Contents.

So far we’ve been working on a simple one page application. Now we want to introduce another page – the dashboard.

For simplicity sake for this project, we are going to have the dashboard page display just two items: some user details and the latest message.

Note: You can find all the source code to this project on GitHub, this chapter has been tagged ch5-dashboard

Return Values and Callbacks

You can see the full code in commit d68d75d. I won’t go into too much detail as most of it is self explanatory and stuff we have already been over. However there is just one slight thing to look out for in the render() method of the main DashboardView.

  render: function () {
    var self = this;
 
    ...
 
    var userDetails = new UserView();
    self.$el.append(userDetails.render());
 
    var messageView = new MessageView();
    messageView.loadMessage(function(el) {
      self.$el.append(el);
    });
  },

The userDetails should be quite straight forward. All it is doing is appending the return value of the UserView‘s render() method to the DashboardView‘s DOM element.

The render() method simply returns the view’s el property.

  render: function () {
    ...
    return this.el;
  },

The loadMessage() method is doing almost exactly the same thing, but because it is having to retrieve some JSON from the server, so instead of returning the el property to passes it as a parameter to a callback:

  loadMessage: function (callback) {
    var self = this;
    self.model.fetch({success: function () {
      self.render();
      callback(self.el);
    }});
  },

Copy/Paste Naughtiness

Look at the code in dashboard.js. Do you see something horrible going on? Yes. Most of it is just copied and pasted from list.js.

This is fantastically bad practice. What if we want to change how the “nice date” is formatted? We’ll have to change it in multiple places.

Nope, this type of coding will not do. We need to turn our attention to reusing components.

Conclusion

OK, so now we have multiple pages within our application. But we have bodged this together and it isn’t very elegant. There is a load of copy and paste nastiness going on which I don’t much like, and this is something we’ll address next time.

But why would we want a multi-page application in the first place?

One reason is that it supports a fallback version much more easily – we could have a simple html website with multiple pages as the fallback version and then layer the multi-page Backbone app over the top.

Another reason is that this sort of html structure also helps with SEO, especially with a well chosen URL structure to match.

Finally, and this is a much more subjective and personal reason, it just makes more sense in my head. If the application has a number of different sections (dashboard, inbox, settings etc) then to me it make more sense to break it down into the distinct sections.

Multi-page or single page, this is your choice.

Reminder: You can find all the source code to this project on GitHub, this chapter has been tagged ch5-dashboard