Component Life Cycle
In general, the Component architecture in 2.0 will "just work." It's been designed to handle most of the management of components transparently to the end developer. However, there will come a time when something needs to be customized, or a Component needs to be extended. That's when a thorough understanding of the Component life cycle will become quite helpful. Following are the most important stages in the life cycle of every class based on Component:
1. Initialization:
The config object is applied
Classes that extend Component do not need to (and usually should not) provide a separate constructor. Component's constructor will not only apply any config passed into its subclasses, it also provides all of the following steps.
The base Component events are created
These are events that can be fired by any Component, and they are enable, disable, beforeshow, show, beforehide, hide, beforerender, render, beforedestroy, destroy (see the Component API docs for complete details).
The component is registered in ComponentMgr
As such it will always be available via Ext.getCmp.
The initComponent method is called
This is the most important initialization step for subclasses, as this is a template method intended to be implemented by each subclass to provide any needed constructor logic. The class being created is called first, and each class in the hierarchy back up to Component is expected to call superclass.initComponent. This method makes it easy to implement and, if needed, override the constructor logic at any step in the hierarchy.
Plugins are loaded (if applicable)
If this Component has any plugins specified in the config, they will be initialized at this time.
State is initialized (if applicable)
If the Component is state-aware, its state will be reloaded if available.
The component is rendered (if applicable)
The component is rendered immediately if either renderTo or applyTo is provided in the config, otherwise rendering is deferred until the Component is explicitly displayed in code or is told to render by its container.
2. Rendering:
The beforerender event is fired
This is a cancelable event, giving any handler the ability to prevent the Component from rendering if needed.
The container is set
If no container is specified, the parent node of the Component's underlying DOM element is set as the container.
The onRender method is called
This is the most important rendering step for subclasses, as this is a template method intended to be implemented by each subclass to provide the needed rendering logic. The class being created is called first, and each class in the hierarchy back up to Component is expected to call superclass.onRender. This method makes it easy to implement and, if needed, override the rendering logic at any step in the hierarchy.
The Component is "unhidden"
By default, many components are hidden using special CSS classes like "x-hidden". If the autoShow config value is true, any "hide" classes are removed from the component at this time.
Custom class and/or style applied
All Component subclasses support the special config properties of cls and style which are a custom, user-defined CSS class and rule respectively that will be applied to the DOM element underlying this Component. Specifying the cls value is the preferred method for visually customizing a Component and its constituent parts. Since the class will get applied to the topmost wrapper element of the Component's markup, any sub-elements of the Component can be adjusted using standard CSS inheritance rules.
The render event is fired
This is a notification that the Component has been successfully rendered at this point. You can safely assume that its DOM elements are now available to your code if needed. If you attempt to access a Component prior to rendering, it won't be available and you'll get an error.
The afterRender method is called
This is another template method for subclasses that can be implemented or overridden to provide any special post-rendering logic that may be needed. Each subclass is expected to call superclass.afterRender.
The Component is hidden and/or disabled (if applicable)
The hidden and disabled config values are applied at this point.
Any state-specific events are initialized (if applicable)
State-aware Components can declare special events that are specific to loading and saving state. If supplied, any such events will be added.
3. Destruction :
The beforedestroy event is fired
This is a cancelable event, giving any handler the ability to prevent the Component from being destroyed if needed.
The beforeDestroy method is called
This is another template method that can be implemented or overridden to provide any special pre-destruction logic that may be needed. Each subclass is expected to call superclass.beforeDestroy.
Element and its listeners are removed
If the Component has been rendered, its underlying Element's event listeners are removed and the Element itself is then removed from the DOM.
The onDestroy method is called
This is another template method that can be implemented or overridden to provide any special post-destruction logic that may be needed. Each subclass is expected to call superclass.onDestroy. Note that the Container class (and any Container subclasses) provides a default implementation of onDestroy that automatically loops through its items collection and calls destroy on each child Component recursively.
Component is unregistered from ComponentMgr
It will no longer be available via Ext.getCmp.
The destroy event is fired
This is simply a notification that the Component has been successfully destroyed at this point and is no longer available in the DOM.
Event listeners on the Component are removed
The Component itself can have event listeners separately from its underlying Element. If any exist, they are removed.
EXTJS:
Elements
Event Handling
Widget Examples
Application Layout/scope
Ext.extend
Element:
var div = Ext.get('myDiv');
div.setWidth(100);
