Custom Store Constructor? Better Call Parent First

[@brady]

Sencha,

If you extend the Ext.data.Store class in 5.0.0 and want to initialize its filters collection in the constructor, why do you now need to first invoke the callParent method before you can safely do so?

Below is a fiddle demonstrating this phenomenon. Run it as is using the 4.2.1 framework, and the store is initialized. Run as is using the 5.0.0.970, and an error is thrown. Move the me.callParent(…) statement to the beginning of the store’s constructor and the error disappears. This work around works, but why?

@brady

[LesJ]

I'd think this inconsistency with 4.2.2 might be considered a bug or at least this should be documented in the upgrade guide.

[twasink]

The filters value is a configuration value; it's expected to be passed in via the config object or set using the generated setter method.

When the configuration tries to run during the parent constructor, the existing value interferes, and things go wrong.

Two options:

• do the initialisation first.
• pass your custom filters in via the configuration, e.g.:

constructor:  function(config) {  var me = this;
  config = config || {}
  config.filters = me.getMyFilters();
  me.callParent([config]);
},

[LesJ]

Good pointer! This also works:

        constructor:  function(config) {
            var me = this;
            me.callParent([config])
            me.setConfig("filters", me.getMyFilters());
    },

[twasink]

Yeah, that works. Reads kind of weird, though. The setConfig call is equivalent to:

this.setFilters(this.getFilters());

Here's a good rule of thumb:

• prior to invoking the parent constructor, you should only change the config object provided.
• after invoking the parent constructor, you should completely ignore the config object, and access the properties directly (preferably through the generated setters and getters - there are a few classes where these do more than simply wrap the property)

In many cases, the config object is available as a field on the class - but a simple change puts a prefix on the front, breaking your code.

See the docs on configuration (and $configPrefixed) for more.

[twasink]

I'd think this inconsistency with 4.2.2 might be considered a bug or at least this should be documented in the upgrade guide.

It would be a bug - a bug in 4.2.

ExtJS introduced the config object in version 4. The rules for using config were:

• don't set anything _except_ the config values before the constructor;
• never set anything in the config _after_ the constructor.

Ext JS 5 has expanded on the power of configuration, but hasn't changed the rules.