主干JS：如何引导我的应用程序？

Question

I am in the process of building my first really simple Backbone JS app, but I am struggling with a basic thing. While I have acquired a basic understanding of the Backbone JS view on MVC, I am wondering: How am I supposed to bootstrap my application?

I've got all models, views and collections in place, but how do I bring it all together?

Of course, I have to instantiate my router:

new App.Router();
Backbone.history.start();

After that, I instantiate my main view:

new App.Views.Main();

I've read that it's good practice to do this, inside it views should be loaded, events should be handled etc. But how am I supposed to do this?

Doesn't this conflict with the so called best practice to bind stuff to events triggered by the router? I've also read this is the proper way to handle things:

App.vent = _.extend({}, Backbone.Events);

App.Router = Backbone.Router.extend({
  routes: {
    '' : 'index'
  },
  index: function() {
    // Here, params passed to be main view can be passed along to other views
    App.vent.trigger('app:init');
  }
});

So how do I kick off my application properly?

Answer 1

The simple answer is: make your main view dependent of the router, and have the view listen to events from the router. Something along the lines of:

var MyMain = Backbone.View.extend({
    initialize: function(options) {
        this.router = options.router;

        this.listenTo(this.router, 'some route event', this.myroutehandler);
    }

    myroutehandler: function(...) {
        // handle the routing
    }
});

var app = new MyMain({router: new MyRouter()});

Of course, you could invert this dependency by creating a router which is dependent of a view.

There is not much wrong with making the objects dependent of each other, as long as you have a clear understanding of what their singular responsibility is. The main view may well be responsible for handling route events. You may very well introduce another object responsible for tying the pieces together. That would be typically called a "front controller".

Slightly better approach

However, usually it makes more sense to have a model which hold "state" of your application, and have the separate views listen to change events on that model, so they can act accordingly. This usually is the better approach, because it then no longer matters who or what changes the state, and you have the added benefit of having the model validate state transitions, ie, not navigating somewhere if something should prohibit the state from changing.

This model then listens to changes in the routing (whenever a user presses the back button or navigates somewhere) and whenever it's state gets updated from outside, changes the History state without firing events. This way, your views no longer need to know about the router and/or history objects, which makes it more transparent who's responsible for changing history state and delegating the changes of this state throughout your application.