This is a kind of follow up to the last year’s “Improving Ext JS MVC Implementation” post. Since then I have joined Sencha and have been working on Ext JS team for several months. Bringing MVC improvements into Ext JS core made all kinds of sense, so here goes.

In any application that has more than one Controller, there is a question: how do these Controllers communicate? Before Ext JS 4.2, the answer was, by calling each other’s methods directly:

Ext.define('My.controller.Foo', {
    extend: 'Ext.app.Controller',

    onPanelButtonClick: function(button) {
        // Suppose that we need to open a window that is governed
        // by another Controller. To do this, we need to call that
        // Controller`s method:
        try {
            this.getController('Bar').openWindow(button.text);
        }
        catch (ex) {
            Ext.Error.raise('Application error: ' +
                            'Controller Bar is unavailable');
        }
    },

    ...
});

Ext.define('My.controller.Bar', {
    extend: 'Ext.app.Controller',

    openWindow: function(text) {
        ...
    },

    ...
});

This approach is problematic and error prone: not only we have to do lots of unnecessary stuff (try/catch, error raising, saving stack trace, etc) but, what is more important, this error checking happens at run time, when misspelled Controller or method name will lead to our application throwing an exception that the user cannot do a thing about. Of course we can relieve this problem by unit testing our Controllers; however if one Controller calls methods in several other Controllers we would have to instantiate them all, which then in turn will bring their dependencies. This leads to unmanageable and untestable mess very quickly.

Starting with Ext JS 4.2, there is a solution to this problem: Controller events. The code above can be refactored this way:

Ext.define('My.controller.Foo', {
    extend: 'Ext.app.Controller',

    onPanelButtonClick: function(button) {
        // Instead of calling Bar method directly, we fire an event.
        // Controller Bar listens to that event and acts accordingly.
        this.fireEvent('barOpenWindow', button.text);
    },

    ...
});

Ext.define('My.controller.Bar', {
    extend: 'Ext.app.Controller',

    init: function() {
        this.listen({
            // We are using Controller event domain here
            controller: {
                // This selector matches any originating Controller
                '*': {      
                    barOpenWindow: 'openWindow'
                }
            }
        });
    },

    openWindow: function(text) {
        ...
    },

    ...
});

This way we solve the problems discussed above, while achieving very clean logic separation between Controllers. When Controller Foo wants Controller Bar to open a window, it sends a signal which may or may not be honored, depending on Bar’s availability and other factors Foo does not know or care about. This approach also makes Controller unit testing a lot easier: in fact the only thing left to test besides refs and component selectors are controller event handlers; all other logic can be encapsulated in Controller and tested separately. See more on this in Unit testing MVC Controllers guide.

You can also find more information on Event domains in Ext.app.Controller.listen() method documentation.