ESLint rules for projects using the ExtJS framework. These rules are targeted for use with ExtJS 4.x. Pull requests for compatibility with 5.x are welcome!
The two main array iterator functions provided by ExtJS, Ext.Array.forEach
and Ext.Array.each
, differ in that each
provides extra
functionality for early termination and reverse iteration. The forEach
method,
however, will delegate to the browser's native Array.forEach
implementation where available, for performance. So, in situations where the
extra features of each
are not needed, forEach
should be preferred. As the
forEach
documentation says:
[Ext.Array.forEach] will simply delegate to the native Array.prototype.forEach method if supported. It doesn't support stopping the iteration by returning false in the callback function like each. However, performance could be much better in modern browsers comparing with each.
The following patterns are considered warnings:
Ext.Array.each(
['a', 'b'],
function() {
// do something
}
);
Ext.Array.each(
['a', 'b'],
function() {
// do something
},
this,
false
);
The following patterns are not considered warnings:
Ext.Array.forEach(
['a', 'b'],
function() {
// do something
}
);
Ext.Array.each(
['a', 'b'],
function(item) {
if (item === 'a') {
return false;
}
}
);
Ext.Array.each(
['a', 'b'],
function() {
// do something
},
this,
true
);
One problem with larger ExtJS projects is keeping the uses
and
requires
configs for a class synchronized as its body changes
over time and dependencies are added and removed. This rule checks that all
external references within a particular class have a corresponding entry in the
uses
or requires
config, and that there are no extraneous dependencies
listed in the class configuration that are not referenced in the class body.
The following patterns are considered warnings:
Ext.define('App', {
requires: ['Ext.panel.Panel']
});
Ext.define('App', {
constructor: function() {
this.panel = new Ext.panel.Panel();
}
});
The following patterns are not considered warnings:
Ext.define('App', {
requires: ['Ext.panel.Panel'],
constructor: function() {
this.panel = new Ext.panel.Panel();
}
});
Ext.define('App', {
extend: 'Ext.panel.Panel'
});
While using Ext.create
for instantiation has some benefits
during development, mainly synchronous loading of missing classes, it remains
slower than the new
operator due to its extra overhead. For projects with
properly configured uses
and requires
blocks,
the extra features of Ext.create
are not needed, so the new
keyword should
be preferred in cases where the class name is static. This is confirmed by
Sencha employees, one of whom has said:
'Ext.create' is slower than 'new'. Its chief benefit is for situations where the class name is a dynamic value and 'new' is not an option. As long as the 'requires' declarations are correct, the overhead of 'Ext.create' is simply not needed.
The following patterns are considered warnings:
var panel = Ext.create('Ext.util.Something', {
someConfig: true
});
The following patterns are not considered warnings:
var panel = new Ext.util.Something({
someConfig: true
});
var panel = Ext.create(getDynamicClassName(), {
config: true
});
Best practices for ExtJS 4 dictate that each class definition be placed in its own file, and that the filename should correspond to the class being defined therein. This rule checks that there is no more than one top-level class definition included per file.
The following patterns are considered warnings:
// all in one file
Ext.define('App.First', {
// ...
});
Ext.define('App.Second', {
// ...
});
The following patterns are not considered warnings:
// file a
Ext.define('App', {
// class definition
});
// file b
Ext.define('App', {
dynamicDefine: function() {
Ext.define('Dynamic' + Ext.id(), {
// class definition
});
}
});