1
votes

I have been looking at Backbone Marionette for sometime, have been mimicking parts of it for my own pure Backbone application. Looks really promising, but 1 thing that I am not sure about is the Modules structure and order in which initializers run. Mainly regarding Backbone.history.start

I am thinking I will have a top level Application that contains modules like Auth, Todo, Comments etc (I usually start with a simple todo app to try out frameworks). Each module will have its own routes. In my understanding, they will have to be initialized before I do Backbone.history.start(). Do I just trigger all modules to start in my top level Application, then start history? This will ensure module routers are initialized before starting Backbone.history. This sounds like starting potentially unneeded modules, thus slowing down the app?

Of course, most apps I know, don't need to be very large, do startup speed is probably acceptable. However I wonder whats the best practice or recommendation

1

1 Answers

2
votes

Modules start with the parent application by default, but you can override this:

A sub-module can override this behavior by setting it's startWithParent to false. This prevents it from being started by the parent's start call.

You can then call MyApp.MyModule.start() manually whenever you'd like.

When you call Application.start(), modules are run in reverse order. From the docs:

Starting of sub-modules is done in a depth-first hierarchy traversal. That is, a hierarchy of Foo.Bar.Baz will start Baz first, then Bar, and finally `Foo.

You'll want to call Backbone.history.start() after calling Application.start(), with at least one router instantiated in the Application. You shouldn't have any problems instantiating additional routers after calling Backbone.history.start() (at least according to this answer from BB.Marionette's Derick Bailey)