ExtJS4 - overrides, mixins, modules

Basically, using modules we can abstract common code into reusable blocks, and then include them into one or more classes later. This has several advantages – avoiding code repetition, decoupling code concepts and ease of unit testing among them.

While the idea is good, there is a better way of achieving this.. Let’s say we define the following modules, which are just plain old objects:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

//module providing geolocation services to a class var GeoLocate = {   findZipLatLng: function(zipCode) {     //does some clever stuff to find a zip codes latitude/longitude   },       getGeoApiKey: function() {     return this.geo_api_key || 'default key';   } }; //module allowing a class to act as a state machine var StateMachine = {   transition: function(stateName) {     this.state = stateName;   },       inState: function(stateName) {     return this.state == stateName;   } };

We’ve got a couple of fictional modules, providing geolocation and state machine functionality. Adding these to an ExtJS class is actually pretty simple:

1 2	Ext.override(Ext.form.FormPanel, StateMachine); Ext.override(Ext.form.FormPanel, GeoLocate);

All that happens above is each property of our module object is copied to Ext.form.FormPanel’s prototype, making the functions available to all FormPanel instances.

If we just wanted to mix our modules into a specific instance of a class, we can do it like this:

1 2 3

var myForm = new Ext.form.FormPanel({}); Ext.apply(myForm, StateMachine);

This will only affect the instance we’re applying to, leaving all other FormPanel instances alone. In Praveen’s example this is in fact all we need to do – there is no need to do the constructor definition and Ext.extend call, we can just use Ext.apply.

There’s nothing in the above that’s actually limited to Ext JS – all we’re doing is copying properties from one object to another. Implementing Ext.override and Ext.apply are pretty simple without Ext itself.

Finally, see overwriting existing properties (functions or objects) on the class you are mixing into. If your formpanel already has a ‘transition’ function it will be overwritten by your module, which could lead to unexpected behaviour. At the instance level you could buy some protection against that by using Ext.applyIf instead of Ext.apply, though you might be safer writing a custom mixin function which can provide access to the original function or raise an exception when overwriting an existing property.

Example for Mixins:
1.

Ext.define('CanSing', {
     sing: function() {
         alert("I'm on the highway to hell...")
     }
});

Ext.define('Musician', {
     mixins: ['CanSing']
})

Ext.define('Musician', {
     mixins: {
         canSing: 'CanSing'
     },

     sing: function() {
         // delegate singing operation to mixin
         this.mixins.canSing.sing.call(this);
     }
})

Example2:

Ext.define("Person", {
    extend: "Ext.Base",
    mixins: {
        observable: "Ext.util.Observable"
    },
    constructor: function(config) {
        this.addEvents();
    }
});

var person = Ext.create("Person");

person.on("eat", function() {
    console.log("I'm eating");
});

person.fireEvent("eat");

Example 2: Override store.loadData() method as below,

Ext.override(Ext.data.Store, {
    loadDataViaReader : function(data, append) {
        var me      = this,
            result  = me.proxy.reader.read(data),
            records = result.records;

        me.loadRecords(records, { addRecords: append });
        me.fireEvent('load', me, result.records, true);
    }            
}); 

Then call above override method using your store instance.

myStore.loadDataViaReader(data);

Reference:

http://edspencer.net/2009/10/02/extjs-modules-and-mixins/