In the earlier Part 1 post, we looked into what System events are and how they work in Lightning Components framework. In this part, we’ll look into which events are fired and in what order for couple of common scenarios. Understanding this will help us know where to keep our business logic and avoid taking performance hit. So let’s take a look at various scenarios.

Scenario 1: Initial Component Creation

This is the basic scenario of component creation without any data update from the server. The framework fires:

1. init event to allow us to set some value,

2. Then it fires render to allow us to customize the markup

3. Finally it fires afterRender to allow us to further change an already rendered component.

Things To Note:

Every event in Scenario 1 is fired only once! so, keep your business logic that needs to run only once in these handlers for example:

1. Handle making a server call when the component is loaded in “init”

2. Similarly handle animation in afterRender.

Scenario 2: When value of a component attribute is changed

When a component’s value changes due to user action like a button click or some other event like component/application event. In this case the framework fires:

1. valueChange to allow us to listen to some attribute to do something.

2. Then it fires rerender (not “render”) to let us update component upon rerendering of the component

3. Eventually doneRendering (not “afterRender”) is called when it’s done rerendering

Things To Note:

This scenario is run whenever any attribute value of the component is changed. So these are run multiple times!

• Keep any logic that needs to be updated whenever there is a change.

• Use Helper to centralize logic in “render” + “rerender” or “afterRender” + “doneRendering”

Scenario 3: When Apex call is made to update data

When we make an Apex call using $A.enqueueAction(), the framework fires:

1. waiting event to allow us to show visual indication like “waiting..” or a “spinner” to the user

2. doneWaiting event is triggered to allow us to hide any visual indication

3. valueChange is fired ONLY IF the callback updates some value

4. rerender if a value is changed  just like in Scenario 2

5. doneRendering is eventually called just like in Scenario 2

Things To Note:

1. waiting and doneWaiting are always fired whenever we use  $A.enqueueAction()
2. However valueChange, rerender and doneRendering are only fired if our business logic changes some attribute value of the component.

Scenario 4: When a component is deleted

Framework fires an unrender event when the component is deleted.

Summary

1. Different set of system events are fired for different scenarios

2. Some set of events are triggered only once (those in Scenario 1 and Scenario 4), whereas others are triggered multiple times (those in Scenario 2 and Scenario 3).

3. Use Helper to refactor and keep logic across scenarios. For example: if you want to animate when the component shows up (scenario 1) and also when it’s updated(scenario 2), you can keep the logic of “afterRender” and “doneRendering” in a Helper.

Note: This blog covers only a subset of system events that are most commonly used. There are several other System events like valueDestroy, locationChange and so on.  You can see all of them in your-salesforce-instance/auradocs reference app that runs inside your org.

If you have any questions, please post it in the comment or ping me at: @rajaraodv