我在构建ExtJS 4中的应用程序时遇到了困难，其中一部分原因是不清楚何时在initComponent()中配置某些内容，何时不需要...
例如，在Sencha自己的MVC应用程序架构文档中，当首次创建网格视图时，他们在initComponent()方法中定义了内联存储。(请参见“定义视图”部分）
向下滚动时，当他们将存储器拆分为单独的类时，他们将其定义移到了initComponent()之外。有一个有用的评论引起了人们对此事的注意，但没有解释。(请参见创建模型和存储器部分)
我想理由应该很明显，但我还是没看出来。有什么指针吗？
initComponent()中声明所有非原始类型。initComponent之外）中声明的任何非原始配置都将在所有实例之间共享。initComponent中严格执行，可以在任何方法中执行，然后通常由constructor、initComponent或其他方法调用。你能否提供一个反对这种做法的建议或最佳实践的链接？ - srainitComponent() 中。对我来说很重要的是知道我是否提供了错误的信息。请问您能否更好地解释一下为什么您认为不应该给出这个建议？ - Izhaki首先，我会表明我的评论立场：
@AlexanderTokarev 别误解我的意思。我不是在谈论组件的配置，更不是关于实例和将它们移动到initComponent()中的配置，这不是我的重点。
现在我对此的想法。
initComponent()应该解决在创建这个类的实例时所需的任何内容。没有多余，也没有缺少。
在定义类时，你可能会弄错一个加载过程，大多数情况下是因为人们不理解ExtJS类系统的工作原理。由于涉及组件，下面将专注于这方面并提供一个简化的示例，只展示我经常看到的一种错误。
让我们开始吧：我们有一个定制面板，可以进行许多巧妙的操作。这需要一个自定义配置，我们称之为foo。我们将其与默认配置选项一起添加到类定义中，以便我们可以访问它：
Ext.define('Custom', {
extend: 'Ext.panel.Panel',
alias: 'widget.custpanel',
foo: {
bar: null
},
initComponent: function() {
this.callParent(arguments);
}
});
测试后，情况变得很奇怪。我们配置的值似乎会神奇地改变。这是一个JSFiddle。
发生的事情是所有创建的实例都指向同一个foo实例。但是最近我已经做到了。
store: {
fields: [ ... ],
proxy: {
type: 'direct',
directFn: 'Direct.Store.getData'
}
}
有一个带有存储器的代码可以正常工作，那么为什么foo不行呢？
大多数人看不出这个小的foo对象和(ExtJS) config之间的区别，因为两者都是对象(实例)。但区别在于由sencha提供的所有类都非常清楚地知道它们期望的配置属性，并对其进行处理。
例如，网格的存储属性通过StoreManager解析，因此可以是:
storeId字符串，或者在初始化网格时，这些选项之一会得到解决并被一个实际的存储实例覆盖。存储只是一个示例。我猜更为人所知的是items数组。这是一个在定义时的数组，并在每个实例中用MixedCollection覆盖(如果我没有弄错的话)。
是的，类定义和从它创建的实例之间有区别。但我们需要注意任何包含引用的新属性，比如上面的foo，这并不复杂。下面是我们需要为foo示例修复它的方法：
Ext.define('Custom', {
extend: 'Ext.panel.Panel',
alias: 'widget.custpanel',
foo: {
bar: null
},
initComponent: function() {
this.foo = Ext.apply({}, this.foo);
this.callParent(arguments);
}
});
这是JSFiddle链接。
现在我们来处理实例创建时的foo配置。现在这个foo示例被简化了，解析配置可能并不总是那么容易。
结论
始终将类定义写成配置！除了纯粹的配置之外，它们不得包含任何被引用的实例，并且必须在创建实例时注意解决这些配置。
免责声明
我并不保证这篇短文涵盖了所有内容！
this.foo = Ext.apply({}, this.foo); 这样的代码在 ExtJS 库中并不明显或清晰。那么，如果没有一篇适当的 Sencha 文章，用户如何理解这些（相当复杂的主题）呢？ - Izhaki我通常倾向于将尽可能多的配置放在类配置选项中，因为这样更易于阅读并且更容易在子类中进行覆盖。此外，未来 Sencha Cmd 很有可能会有一种优化编译器，因此，如果您保持代码的声明性，它可能会受益于优化。
比较：
Ext.define('MyPanel', {
extend: 'Ext.grid.Panel',
initComponent: function() {
this.callParent();
this.store = new Ext.data.Store({
fields: [ ... ],
proxy: {
type: 'direct',
directFn: Direct.Store.getData
}
});
this.foo = 'bar';
}
});
...
var panel = new MyPanel();
而且：
Ext.define('MyPanel', {
extend: 'Ext.grid.Panel',
alias: 'widget.mypanel',
foo: 'bar',
store: {
fields: [ ... ],
proxy: {
type: 'direct',
directFn: 'Direct.Store.getData'
}
}
});
...
var panel = Ext.widget({
xtype: 'mypanel',
foo: 'baz'
});
Ext.app.Controller和Ext.app.Application。initComponent中硬编码数据几乎相同：当然可以工作，但只能到一定程度。然后它变成了一碗意大利面条，难以维护和扩展。哦，还有测试所有这些！恶心。control。您将不得不从对象实例获取实际函数引用，并且您必须在initComponent或init中执行此操作。但是，我们正在努力解决这个问题 - 没有硬编码所有这些的硬要求；Observable.on()已经支持字符串侦听器名称，MVC之类的内容也很快就会支持。store不是一个属性，而是一个配置选项 - 因为Ext.define处理的是类而不是实例。当创建给定类的实例时，会定义属性 - 但不会更早。这样，store不是“特殊已知的属性”，它是一个配置选项，恰好与将在对象实例化时创建的实例属性具有相同的名称。 - Alex Tokarev我在寻找答案时也遇到了同样的问题，看到这些答案让我感到失望。没有一个回答这个问题：initComponent()还是constructor？
很高兴知道类配置选项对象是共享的，您需要针对每个实例进行初始化/处理，但代码可以放在构造函数中，也可以放在initComponent()函数中。
我的猜测是，组件类的构造函数在中间某个位置调用initComponent()，我并没有非常错误：只需要查看源代码，实际上是AbstractComponent的构造函数。
所以看起来是这样的：
AbstractComponent/ctor:
- stuffBeforeIC()
- initComponent()
- stuffAfterIC()
constructor: function () {
yourStuffBefore();
this.callParent(arguments);
yourStuffAfter();
},
initComponent: function () {
this.callParent();
yourInitComp()
}
- yourStuffBefore()
- base's ctor by callParent:
- stuffBeforeIC()
- initComponent:
- base's initComponent by callParent
- yourInitComp()
- stuffAfterIC()
- yourStuffAfter()
所以最终一切都取决于您是否想/需要在stuffBeforeIC和stuffAfterIC之间注入您的代码，这些内容可以在您将要扩展的类的构造函数中查找。