Server-Side Processing for Component Requests

A component lifecycle starts when the client sends an HTTP request to the server, which can be in the form http://<yourServer>/<namespace>/<component>.cmp. Attributes can be included in the query string, such as http://<yourServer>/<namespace>/<component>.cmp?title=Component1. If attributes are not specified, the defaults that are defined in the attribute definition are used.

For a component request, the server:

1. Load registries and locates component definitions.
2. Build or retrieves component definitions.
3. Instantiate component definitions.
4. Serialize component definitions and instances.
5. Send serialized component definitions and instances to the client.

1. Load registries and locate component definitions.

When the server receives an HTTP request, the Aura framework is loaded according to the specified mode. AuraContextFilter creates a AuraContext, which contains the mode denoted by the aura.mode parameter in the URL, such as in http://<yourServer>/namespace/<component>.cmp?aura.mode=PROD. Aura uses the default mode if the aura.mode parameter is not included in the query string.

The server receives and parses the request for an instance of a component definition (ComponentDef). If attributes are included, Aura converts them to strongly typed attributes for the component definition.

Next, the registries are loaded. Registries store metadata for Aura objects. They may be created during the request process and destroyed when the server completes the request.

A master definition registry (MasterDefRegistry) contains a list of registries (DefRegistry) that are used to load and cache definitions. A separate registry is used for each Aura object, such as actions, or controllers.

2. Build or retrieve component definitions.

This stage of the process retrieves the component's metadata, known as the ComponentDef.

Any dependencies on other definitions are also determined. Dependencies may include definitions for interfaces, controllers, actions, and models. A DefRegistry that doesn't contain the ComponentDef passes the request to a DefFactory, which builds the definition.

Each component definition in the tree is parsed iteratively. The process is completed when the ComponentDef tree doesn't contain any unparsed ComponentDefs.

3. Instantiate component definitions.

Once the server completes the component definition process, it can create a component instance. To start this instantiation, the ComponentDef (a root definition) is retrieved along with any attribute definitions and references to other components. The next steps are:

• Determine component definition type: Aura determines whether the root component definition is abstract or concrete.
• Create component instances:
  • Abstract: Aura can instantiate abstract component definitions using a provider to determine the concrete component to use at runtime.
  • Concrete: Aura constructs a component instance and any properties associated with it, along with its super component. Attribute values of the component definitions are loaded, and can consist of other component definitions, which are instantiated recursively.
• Create model instances: After the super component definition is instantiated, Aura creates any associated component model that hasn't been instantiated.
• Create attribute instances: Aura instantiates all remaining attributes. If the attribute refers to an uninstantiated component definition, the latter is instantiated. Non-component attribute values may come from a client request as a literal or expression, which can be derived from a super component definition, a model, or other component definitions. Expressions can be resolved on the client side to allow data to be refreshed dynamically.

The instantiation process terminates when the component and all its child nodes have been instantiated. Note that controllers are not instantiated since they are static and don't have any state.

4. Serialize component definition and instances.

Aura enables dynamic rendering on the client side through a JSON serialization process, which begins after instantiation completes. Aura serializes:

• The component instance tree
• Data for the component instance tree
• Metadata for the component instance tree

When the current object has been serialized but it's not the root object corresponding to the requested component, its parent objects are serialized recursively.

5. Send serialized component definitions and instances to client.

The server sends the serialized component definitions and instances to the client. Definitions are cached but the instance data is not cached.

The definitions are transmitted in the following format:

1swfobject.registerObject("clippy.codeblock-0", "9");{"descriptor":"markup://aura:component",
2"rendererDef":{ "serRefId":2},
3"attributeDefs":[{ "serId":20,
4                    "value":{ "descriptor":"body",
5                    "typeDefDescriptor":"aura://Aura.Component[]",
6                    "required":false} } ],
7                    "interfaces":["markup://aura:rootComponent"],
8                    "isAbstract":true}

The component instance tree is transmitted in the following format:

1swfobject.registerObject("clippy.codeblock-1", "9");$A.initAsync({"context":{"mode":"DEV","app":"auradocs:sample",
2       "requestedLocales":["en_US","en"]},
3       "deftype":"APPLICATION",
4       "descriptor":"markup://auradocs:sample",
5       "host":"",
6       "lastmod":1323498293847});