An interesting observation about both routing and data binding is that they are built around events. When a route changes, an event is fired and a controller listens to it, setting the application's state accordingly. When a property is data bound, Ext JS publishes its changes and other properties listen for these changes.

We're also familiar with events, such as click, select, show, and so on, that are fired from the various Ext JS components. It would seem that as events are being used everywhere in an Ext JS application, we might as well make use of them ourselves!

We can use fireEvent from every Observable class in Ext JS. This allows you to fire a custom event from pretty much anywhere in our application. In previous versions of Ext JS, you needed to define events beforehand using an addEvent method, but this is no longer the case. However, what use is this? Does it offer a real-world advantage? Let's look at some bad code to demonstrate:

// Theoretical "messages" view controller
message.save({
    success: function(response) {
          var viewport = Ext.ComponentQuery.query('viewport')[0];
          
          // Refresh the list of records after adding this one.
          viewport.down('list').getStore().reload();

          viewport.showMessage(response.message);

          this.lookupReference('editor').hide();
   },
   scope: this
});

We save a message record. Then, in the callback, reload a list store, show a message in the viewport, and hide an editor component.

That's three separate things, only one of which—hiding the editor—is probably in the right place. The others should be handled by their own view controllers. This code would be much better:

message.save({
    success: function(response) {
          this.fireEvent('messagesaved', response.message.id);
   },
   scope: this
});

Now, any code anywhere in the application can listen for a messagesaved event and proceed accordingly. The key benefit this brings is that this example message view controller doesn't have to know anything about any other views, controllers, or even anything about the rest of the application.

This makes the messages view and view controller much more resistant to any changes in the rest of the system and much easier to test. In theory, it could be pulled out of the application and tested standalone.