Controller - Sencha Ext JS 5+


Controller classes retrieve component instances, and respond to component events. Controllers are created at application launch, and remain present for the life of the application, during which time views of interest to a controller come and go. A single controller can manage multiple view instances.

ViewControllers, introduced in Ext JS 5+, solve the following problems for large applications that existed for previous versions of Ext JS...


The following listener has a named event handler, onBarChange, with no specified scope. The event system resolves the default scope to the ViewController that owns onBarChange.

For a view to listen to its own events, or those fired by its base class, use an explicit scope:

When writing MVC applications, we almost always use "controller" which enables looking on that view's ViewController, not the ViewController of the view that created the instance.

Since a view is a type of Ext.Component, we have assigned this view an "xtype" which enables other views to create an instance of our view in the same way this view created its textfield. In the following example, the Bar view is creating an instance of the Foo view as one of its items. The Bar view is listening to the collapse event just like the Foo view. The listeners declared by the Foo view will fire on Foo's ViewController while the listeners declared in the Bar view will fire on Bar's ViewController.


To get a reference to a component, use the "reference" config.

The lookupReference method consults the cache to see if references need to be refreshed.

To complete this model, views need to fire events that can be consumed by their owning view's ViewController. There is a helper method in ViewController for this purpose: fireViewEvent. For example:

This enables the standard form of listener for the creator of this view:

Listeners and Event Domains

In Ext JS 4.2, the MVC event dispatcher was generalized with the introduction of event domains. These event domains intercepted events as they were fired and dispatched them to controllers controlled by selector matching. The “component” event domain had full component query selectors while the other domains had more limited selectors. With Ext JS 5+, each ViewController creates an instance of a new type of event domain called the “view” event domain. This event domain allows ViewControllers to use the standard listen and control methods while limiting their scope implicitly to their view. It also adds a special selector to match the view itself:

The button selector will match any button in this view or any child view, irrespective of depth.

These event domains respect nesting and bubble an event up the view hierarchy. When an event fires.

Life Cycle

A common technique with large applications is to dynamically create controllers when they are first needed. This helps reduce the load time of the application by not activating all potential controllers. The limitation to this in previous versions was that, once created, these controllers would remain active in the application. It was not possible to destroy them and release their resources. Likewise, this did not change the reality that a controller could have any number of associated views (including none).

The ViewController, however, is created very early in the component's lifecycle, and is bound to that view for its entire lifetime. When that view is destroyed, the ViewController is likewise destroyed. The ViewController is no longer forced to manage states where there is no view or many views.

This one-to-one relationship means reference tracking is simplified, and no longer prone to leaking destroyed components. A ViewController can implement any of these methods to perform tasks at key points in its lifecycle:

Method Description
beforeInit Can be overridden in order to operate on the view prior to its initComponent method being called. This method is called immediately after the controller is created, which occurs during initConfig called from the Component constructor.
init Called shortly after initComponent has been called on the view. This is the typical time to perform initialization for the controller now that the view is initialized.
initViewModel Called when the view's ViewModel is created (if one is defined).
destroy Cleanup and return resources (be sure to call callParent).

Previous | Home | Next