Question

I’m currently writing a Backbone Marionette app which ultimately amounts to about 6 different “screens” or pages which will often times share content and I am unsure of how to best structure and access Regions.

I am using the app/module setup described here: StackOverflow question 11070408: How to define/use several routings using backbone and require.js. This will be an application which will have new functionality and content added to it over time and need to be scalable (and obviously as re-usable as possible)

The Single Page App I’m building has 4 primary sections on every screen: Header, Primary Content, Secondary Content, Footer.

The footer will be consistent across all pages, the header will be the same on 3 of the pages, and slightly modified (using about 80% of the same elements/content) on the remaining 3 pages. The “morecontent” region will be re-usable across various pages.

In my app.js file I’m defining my regions like so:

define(['views/LandingScreen', 'views/Header', 'router'], function(LandingScreen, Header, Router) {
    "use strict";
    var App = new Backbone.Marionette.Application();

    App.addRegions({
        header: '#mainHeader',
        maincontent: '#mainContent',
        morecontent: '#moreContent',
        footer: '#mainFooter'
    });

    App.addInitializer(function (options) {

    });

    App.on("initialize:after", function () {
        if (!Backbone.History.started) Backbone.history.start();
    });

    return App;
});

Now, referring back to the app setup in the aforementioned post, what would be the best way to handle the Regions. Would I independently re-declare each region in each sub-app? That seems to be the best way to keep modules as independent as possible. If I go that route, what would be the best way to open/close or hide/show those regions between the sub-apps?

Or, do I keep the Regions declared in app.js? If so, how would I then best alter and orchestrate events those regions from sub-apps? Having the Regions defined in the app.js file seems to be counter-intuitive to keeping what modules and the core app know about each other to a minimum. Plus, every example I see has the appRegions method in the main app file. What then is the best practice for accessing and changing those regions from the sub-app?

Thanks in advance!

Answer 1

I actually have a root app that takes care of starting up sub-applications, and it passes in the region in which they should display. I also use a custom component based off of Backbone.SubRoute that enables relative routing for sub-applications.

check out this gist: https://gist.github.com/4185418

You could easily adapt it to send a “config” object for addRegions that defines multiple regions, instead of the region value I’m sending to the sub-applications’ start method

Keep in mind that whenever you call someRegion.show(view) in Marionette, it’s going to first close whatever view is currently being shown in it. If you have two different regions, each defined in its own app, but both of which bind to the same DOM element, the only thing that matters is which region had show called most recently. That’s messy, though, because you’re not getting the advantages of closing the previous view – unbinding Event Binders, for example.

That’s why, if I have a sub-app that “inherits” a region from some kind of root app, I usually just pass in the actual region instance from that root app to the sub-app, and save a reference to that region as a property of the sub-app. That way I can still call subApp.regionName.show(view) and it works perfectly – the only thing that might screw up is your event chain if you’re trying to bubble events up from your region to your application (as the region will belong to the root app, rather than the sub-app). I get around this issue by almost always using a separate instance of Marionette.EventAggregator to manage events, rather than relying on the built-in capabilities of regions/views/controllers/etc.

That said, you can get the best of both worlds – you can pass the region instance into your sub-app, save a reference to it just so you can call “close”, then use its regionInstance.el property to define your own region instance pointing to the same element.

for(var reg in regions) if regions.hasOwnProperty(reg) {
    var regionManager = Marionette.Region.buildRegion(regions[reg].el,
            Marionette.Region);
    thisApp[reg] = regionManager;
}

It all depends on what your priorities are.