我在 ExtJS 4 中构建应用程序时遇到了困难，其中一部分是混淆了何时在 initComponent() 中配置某些内容以及何时不...
例如，在 Sencha 自己的MVC Application Architecture 文档中，在第一次创建网格视图时，他们在 initComponent() 方法中定义了内联存储。 （参见“定义视图”部分）
更进一步，当他们将 store 分解为一个单独的类时，他们将定义移到了 initComponent() 之外。有一个有用的评论提请注意这一事实，但没有解释。 （请参阅创建模型和存储部分）
我想原因应该很明显，但我错过了。有什么指点吗？
【问题讨论】：
如果您对 ExtJS 类系统的工作原理没有深入了解，您可能需要遵循以下内容：
在
initComponent()中声明所有非原始类型。
如果要多次创建您扩展的组件，则任何声明为配置选项（initComponent 之外）的非原始配置将在所有实例之间共享。
因此，当在多个选项卡上创建扩展组件（通常是扩展网格）时，许多人都会遇到问题。
以下 sra 的回答和 this Skirtle's Den article 中解释了此行为。您可能还想阅读this SO question。
【讨论】：
initComponent 它可以通过任何通常由constructor 或initComponent 甚至任何其他方法调用的方法来完成。您能否将我链接到与此相反的建议或最佳实践？
initComponent()。知道我是否提供了错误信息对我来说很重要。您能否更好地解释为什么您认为不应给出此建议？
initComponent 给人一种解决问题的印象，但实际上它只是将其转移到其他地方。根据经验，您应该避免手动创建组件 - 使用子类来应用配置选项和存储组件类所需的逻辑，然后通过 xtype 再次将它们重用为配置选项。我会在下面的回答中尝试更多地解释它。
首先我要对我的评论表明立场：
@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）配置之间有任何区别，这基本上是正确的，因为两者都是对象（实例）。但不同之处在于，所有由 sencha 提供的类都非常清楚他们期望和处理的配置属性。
例如，网格的 store 属性由 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 示例已经简化，解析配置并不总是那么容易。
结论
始终将您的类定义写为配置！他们不得 包含除普通配置外的任何引用实例，并且必须 在创建实例时处理这些问题以解决它们。
免责声明
我并没有声称用这篇非常短的文章来涵盖所有内容！
【讨论】：
store 是出了名的错误示例：理论上，它应该只接受字符串 storeId 或存储配置对象，因为它们是不可变的。但它也接受商店实例，用于歇斯底里的葡萄干，这就是让人们感到困惑的地方。
this.foo = Ext.apply({}, this.foo); 这样的行在 ExtJS 库中不可见或不清晰。那么用户如何在没有适当的 Sencha 文章的情况下掌握这些（相当复杂的主题）？
我通常主张在类配置选项中尽可能多地进行配置，因为它读起来更好并且更容易在子类中覆盖。除此之外，很有可能在未来 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'
});
请注意这些方法有何不同。在第一个示例中，我们进行了很多硬编码：对象属性值、存储配置、使用时的 MyPanel 类名；我们实际上扼杀了类的想法，因为它变得不可扩展。在第二个示例中，我们正在创建一个模板，它可以通过可能的不同配置多次重复使用——基本上，这就是整个类系统的意义所在。
但是，实际的区别更深。在第一种情况下，我们有效地将类配置推迟到运行时，而在第二种情况下，我们定义类配置并在非常不同的阶段应用它。事实上，我们可以很容易地说第二种方法引入了 JavaScript 本身缺乏的东西：编译时阶段。它为我们提供了框架代码本身利用的大量可能性；如果您需要一些示例，请查看最新 4.2 beta 中的 Ext.app.Controller 和 Ext.app.Application。
从更实际的角度来看，第二种方法更好，因为它更易于阅读和处理。一旦你掌握了这个想法，你会发现自己编写的所有代码都是这样的，因为这样更容易。
这样看：如果您要编写一个老式 Web 应用程序，在服务器端生成 HTML 和其他内容，您会尽量不将任何 HTML 与代码混合，对吗？左边是模板，右边是代码。这实际上与initComponent 中的硬编码数据相同：在一定程度上，它确实有效。然后它就变成了一碗意大利面，难以维护和扩展。哦，测试所有这些！呸。
现在，有 次您需要在运行时使用 实例 做某事，而不是在类定义时 - 经典示例是应用事件侦听器，或在控制器中调用control。您必须从对象实例中获取实际的函数引用，并且您必须在initComponent 或init 中这样做。然而，我们正在努力解决这个问题——应该没有硬编码所有这些的硬性要求； Observable.on() 已经支持字符串侦听器名称，很快 MVC 也将支持。
正如我在上面的 cmets 中所说，我必须为文档写一篇文章或指南，解释事情。那可能要等到 4.2 发布；同时，希望这个答案能对此事有所启发。
【讨论】：
store 不是一个属性，而是一个配置选项 - 因为Ext.define 处理的是 classes 而不是 instances。创建给定类的实例时，会定义属性 - 但不会更早。这样，store 不是“特殊的已知属性”，它是一个配置选项，恰好与将在对象实例化时创建的实例属性同名。
当我来到这里时，我一直在寻找同一个问题的答案，但看到这些答案让我很失望。这些都没有回答这个问题：initComponent() 还是构造函数？
很高兴知道类配置选项对象是共享的，您需要为每个实例初始化/处理它们，但代码可以进入构造函数以及 initComponent() 函数。
我的猜测是 Component 类的构造函数在中间某处调用了 initComponent()，我并没有错：只需要查看源代码，它实际上是 AbstractComponent's constructor。
所以它看起来像这样：
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 之间注入你的代码，你可以在你要扩展的类的构造函数中查找。
【讨论】：