EXTJS Component Life cycle

EXTJS Component Life Cycle

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.