...
In this case the listener function is created once and stored on the class. Each instance will share the same function. The overhead for creating the function is incurred just once and there's no risk of a leaky closure. Even better, this style of coding makes it easy for subclasses to change the listener with a simple override.
...

How is that different from putting

Code:

listeners: {
load: function(store, records, success){
...
}
}

on the store? Is the function attached to the store in that case, or is it created each time?

9 Nov 2012, 1:03 AM

brohit4

Is there anyway to render Ext components in a dataview without a defered render?

Defered render is eating my time out :(

17 Feb 2013, 11:46 PM

Daniil

First of all, thank you all for sharing your experience!

Quote:

Originally Posted by skirtle

A common myth is that xtypes provide a performance boost through lazy-instantiation. In general this is not true. As soon as you add an xtype-config to a container it will instantiate the full component, even if it isn't visible.

Whilst xtypes have many great uses they usually have no measurable impact upon application performance or resource consumption.

For example, it says the following in the comments within the code sample.

Quote:

// Explicitly define the xtype of this Component configuration.
// This tells the Container (the tab panel in this case)
// to instantiate a Ext.panel.Panel when it deems necessary

Maybe, it just mixes up the "instantiation" and "rendering" terms?

Anyway, your statement and the guide conflict:)

18 Feb 2013, 9:10 AM

mitchellsimoens

No, it will instantiate when needed, when the parent container is created it needs to have it's children instantiated. If you have this:

Code:

Ext.define('MyForm', {
extend : 'Ext.form.Panel',
xtype : 'myform',

items : [
{ xtype : 'textfield', fieldLabel : 'One' }
]
});

So the field instance is of course not created because there is no instance of MyForm. So if we create an instance of MyForm:

Code:

Ext.create('MyForm');

It will create the instance of the field automatically. Notice I didn't tell MyForm to render at all but the field instance will be created. The child items are not instantiated on rendering, they are instantiated when the container is instantiated.

18 Feb 2013, 10:00 PM

Daniil

Mitchell, thank you for the clarification! It is clear.

Though, I think, the guide really can lead to some misunderstanding. For example, here:

Quote:

This is where xtypes come in handy by allowing a Container's children to be configured up front, but not instantiated until the Container determines it is necessary.

Instantiating a Container causes its children to be instantiated. So, I am not sure what "until the Container determines it is necessary" really means. Is "rendering" meant here?

Or, maybe, it is all about the class definition? Well, yes, I expect all to be not instantiated just after the class definition:)

Well, generally, all seems clear for me now. Just I am talking about some inconsistency in the guide.

19 Feb 2013, 6:59 AM

mitchellsimoens

No, rendering is not meant. When you are defining a class, you wouldn't want instances to be made until that class is created so xtypes are handy for that.

19 Feb 2013, 7:23 AM

Daniil

Sure.

Interesting, does something like "instantiation on rendering stage" make sense?

19 Feb 2013, 7:26 AM

mitchellsimoens

Quote:

Originally Posted by Daniil

Sure.

Interesting, does something like "instantiation on rendering stage" make sense?

No, it has nothing to do with rendering. A component doesn't have to be rendered like my example with the form and field. When an instance of the form is created, it requires it's children to be instantiated regardless of if the form is being rendered or not.

19 Feb 2013, 7:31 AM

Daniil

Yes, it is how the things are now.

But I am rather talking about a possible enhancement. Does it really need to instantiate something if it might not be rendered at all?