javascript - examples - sencha

Mejores prácticas sobre initComponent() en Ext.define()

Question

Estoy escribiendo todos mis componentes en la nueva moda MVC de ExtJS usando Ext.define() .

Me cuesta un poco si definir propiedades dentro de initComponent() o simplemente configurándolos como property: 42, initComponent()

¿Hay mejores prácticas ampliamente aceptadas?

Estoy initComponent() entre usar initComponent() solo cuando es necesario (es decir, cuando quiero algo dinámico o establecer un alcance) que mantiene la función más corta y me ahorra algo de feo this. y usarlo siempre que tiene el beneficio, que nunca tendría que mover las propiedades anteriores a initComponent() solo porque quiero hacerlo más dinámico.

Desafortunadamente, los documentos de Sencha no dicen mucho sobre eso y los ejemplos disponibles parecen hacer lo que quieren.

Answer 1

No recibo tu pregunta exactamente, pero esto puede ser útil para ti.

 Ext.define(''My.Group'', {
// extend: ''Ext.form.FieldSet'',
xtype : ''fieldset'',
config : {
title : ''Group'' + i.toString(),
id : ''_group-'' + i.toString()
},
constructor : function(config) {
this.initConfig(config);
return this;
},
collapsible: true,
autoScroll:true,
.....
});

puedes usarlo de la siguiente manera

handler : function() {
i = i + 1;
var group = new My.Group({
title : ''Group'' + i.toString(),
id : ''_group-'' + i.toString()
});
// console.log(this);
// console.log(group);
Ext.getCmp(''panelid'').insert(i, group);
Ext.getCmp(''panelid'').doLayout();
}

Answer 2

Práctica personal, declararé variables en el área de propiedades cuando el

• variables que definen la magnitud, como x , y , width , height
• variables que esperan ser anuladas o personalizables, como title , saveBtnTxt , url , fields , iconCls
• algunas constantes, que tendrán prefijos especiales, por lo que no se anularán tan fácilmente

Luego declararé items , listeners , this.on , Ext.apply(me, {..}) o cualquier cosa que requiera el alcance del obj ( this , me ), para sentarme dentro de mi initComponent . O cosas que deberían modificarse / anularse antes de que todo se configure para que el usuario no rompa mi componente anulando algunas de las variables importantes.

Por supuesto que servirá como mi guía. 2 centavos

EDITAR

Sobre lo feo de this , he utilizado la variable ampliamente en mi aplicación, y se ve mucho más limpio que this . Me beneficia cambiar los ámbitos también con menos frecuencia.

Answer 3

Quiero agregar a la respuesta de Lionel que es mejor declarar cualquier configuración no primitiva en initComponent . (Por primitivo quiero decir cadena, booleano y número). Array y Object entran en initComponent .
Entonces la definición debería verse así:

Ext.define(''My.NewClass'', {
extend: ''OldClass'',
// here all primitive configs:
cls: ''x-my-cls'',
collapsible: true,
region: ''west'',
// and so on ...
initComponent: function() {
// here you declare non-primitive configs:
this.tbar = [/* blah-blah */];
this.columns = [/* blah-blah */];
this.viewConfig = {/* blah-blah */};
// and so on ...
this.callParent(arguments);
}
// other stuff
}

La razón por la que debe poner todas las configuraciones no primitivas en initComponent es que, de lo contrario, las configuraciones de todas las instancias se referirán a los mismos objetos. Por ejemplo, si define NewClass como:

Ext.define(''My.NewClass'', {
extend: ''OldClass'',
bbar: Ext.create(''Ext.toolbar.Toolbar'', {
// ...

bbar s de todas las instancias se referirá al mismo objeto. Y, por lo tanto, cada vez que crea una nueva instancia, bbar desaparece de la instancia precedente.