Skip to content

An example of a sub-router #40

wants to merge 1 commit into from

5 participants

revgum commented Jan 18, 2012

Seems like it might help someone else understand where to hook up a sub-router.

tbranyen commented Feb 8, 2012

I feel like this is better off going into documentation rather than the boilerplate which is all usable code. With this pull request intialize: function() { ... } would be dead code.

I'm thinking this should definitely be in documentation, but I'm not sure it belongs in the source. What do you think?


i have been thinking about this, what if we have a couple of modules each with their own router. we have to require all of them in the main router to initialize. this could became a problem when the app scales, we make modules to decouple things and end up with a bloated main router .

so here my 2cents for discussion: with the module() method we could cache the modules created and in the router initialize we loop through the modules check if a router property exists and create a new sub-router.
but the problem here is we still need to require all the modules somewhere or we wont have the module objects cached and available in the main router.
it makes sense to create some kind of module definition file just to keep track of the modules ? or its just my brain trying to make things more complex ? :D


hdias, I'm struggling with this scaling issue right now. I want my modules to be decoupled and atomic, but it feels like the main.js needs to know everything about my application given the current architecture. Not that I have a better solution ATM :)

What I'd like to do is define a Modules parameter to the callback of require() in main.js and have that contain a list of modules listed in require()'s first param e.g.

function(namespace, $, Backbone, Modules)

I think this is what you meant when you said:

but the problem here is we still need to require all the modules somewhere or we wont have the module objects cached and available in the main router

right, that we can't currently know what Modules we have in the main.js callback?


yes thats what im thinking

to do that we need a new files modules.js with somethings like this:


function(namespace, Example1,Example2,Example3 ) {
    var modules = {};

    return modules;

with that we may do lots of things set parameters for navbar contruction, widget view to be used by another module like a dashboard.. etc etc.
and in the main we require Modules to init the sub routers all a the same time.

or we can do this directly in the namespace file and have it attached to our main object.


I'm not sure if this would be a sensible default for the boilerplate. I can see why you would want to break out your modules into another file... and if that makes it easier and more maintainable for you, by all means go for it. I personally haven't needed that in any of my projects.

@jessebeach you only list modules that you use inside app/main.js if you chose a Modules namespace to access all of them that seems a bit weird to me. Modules.MyModule.Views.Something is also a bit long to type. If you have something I could look at it that is getting hard to scale, I'd like to see what you mean.


I took revgum's example of using the initialize callback for the Router() and added a bit of magic that merges the routes of modules with the main applications routes.


I like it because now my main application just needs to know that its required modules exist; it needs to know very little about their composition, especially their routes, which could change frequently.

This bit of code imposes the supremacy of modules, i.e. that module routes will overwrite main.js routes and later-loaded modules will overwrite the routes of earlier-loaded modules.


Nothing to look at that is not scaling. I was only thinking that if an application got beyond 5 modules, the main.js invocation function parameter list would start to look bloated. It seems a bit brittle to me that application needs to know so much about it's modules, but maybe there's little to do to get around that.

Mostly my code above is a thought experiment.

jhiemer commented Apr 24, 2012

Hi Jesse,
I like your approach very much. Currently my application is planned to have about 20 modules, each responsible for its on section in a B2B application. And I had exactly the same issue, you had. Are you using the solution somewhere, or was it just an experiment?

Edit: Jesse, I tried your branch, but I am always getting an error related to the modules. In specific, the problem is, that the Modules in main.js do not get loaded. So:
var Modules =, arguments.callee.length) || []; results in Models == null. Any idea, why this happens?

jhiemer commented Apr 24, 2012

Hi Jesse,
thanks a lot for your response! I will try and contact him. Are you going to release your prototype here on GitHub, or is it going to be closed source?

Summarizing your answer: the branch you provided is just a base proposal of how sub-routing might work, but not a full implementation, right?


I would love to this in a blog post write up somewhere, but the direction of this project is changing to be a base workflow that is forkable and not trying to account for all development situations.

@tbranyen tbranyen closed this Jul 23, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.