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.