Those of you who have used Vue must be familiar with the life cycle. At the beginning of the official document, we were introduced what the life cycle of Vue is and what order it is. That’s not a problem for you.
But what is the order in which the parent component lifecycle functions fire when components are nested? Are you a little bit unsure?
If so, let’s put our hands together to confirm this simple question.
First, there are eight critical phases in the life cycle of a Vue instance/component:
beforeCreate
: Called after instance initialization and before event/ Watcher event configuration.created
: is called immediately after the instance is created. In this step, the instance completes data Observer, property and method operations, and watch/ Event event callbacks.beforeMount
: called before the mount begins: relevantrender
The function is called for the first time.mounted
: called after the instance is mountedel
Newly createdvm.$el
Replaced.beforeUpdate
: is called when data is updated, and occurs before the virtual DOM is patched.updated
: after the virtual DOM is re-rendered and patched.beforeDestory
: called before instance destruction. At this step, the instance is still fully available.destoryed
: called after instance destruction. All instructions corresponding to the Vue instance are unbound, all event listeners are removed, and all subinstances are destroyed.
We can also take a look at the life cycle diagram [1] on the official website.
For the above eight life cycles, we can divide them into three phases: create mount phase, update phase, and destroy phase.
Let’s take a look at the sequence in which the three phases of the lifecycle are triggered when components are nested.
The sample code: codesandbox. IO/s/qiantaozu…
1. Create a mount phase
If you read the descriptions of the phases carefully, you should be aware that when components are nested, the creation of the mount of the child component is triggered when the parent component is mounted. So let’s make sure.
Opening the sample code, there is no rendering component by default. Click “Show Components” and you will see the following page. The parent and child components will be rendered.
At this point, you can see that the console outputs the triggering order of the parent and child components.
The order is as follows:
You can see that the create mount phase of the child component is indeed completed in the parent component’s mount phase, starting after beforeMount of the parent and ending before Mounted of the parent.
2. Update phase
Again, the update phase is relatively simple, and with the experience above, you can basically determine that the updating process of the child component is between the beforeUpdate and updated of the parent component.
Change the name of the parent component in the page, and you can see that the lifecycle firing order of the output is indeed as expected, as follows:
3. Destruction stage
At this point, there should be nothing more to say about the destruction phase, the destruction of the child component is done between the beforeDestroy and Destroyed of the parent component.
Click on the sample code and uncheck display components to see the following order:
Now let’s extend the official life cycle diagram a bit, adding the life cycle when components are nested. As shown below:
Well, that’s the end of today’s share.
Ha ha, just kidding, obviously not so water, otherwise crooked horse himself can not look down.
So let’s move on. Above we have verified in a simple and intuitive way the order in which lifecycle functions fire when the following components are nested. However, if you are careful, you may have noticed that the examples above are all synchronous components. What happens when the component is asynchronous?
3. If the component is an asynchronous component
Mounted does not guarantee that all children will be mounted. Its updated version does not guarantee that all children will be redrawn together. .
This is explained on the official website because when the component is asynchronous, the lifecycle is triggered in a different order.
Creation and mounting of step-out components
Without further ado, let’s make the component asynchronous and see what happens. Found in the demo SRC/components/OuterBox vue, change the InnerBox to asynchronous loading. Such as:
InnerBox: () => import("./InnerBox")Copy the code
We then re-check the display page and see that when the child is asynchronous, the create mount phase of the child occurs between the beforeUpdate and updated of the parent.
Taking a quick look at the Vue source code, we can see that when a component is an asynchronous component, the factory function of the asynchronous component is executed, and after the component is loaded, all parent components containing the component are forced to update.
The factory function for asynchronous functions is () => import(“./InnerBox”), as the official documentation states, as long as it is a function that returns a Promise. The return value can also be a more complex object with load status, as documented.
// ...
var forceRender = function (renderCompleted) {
for (var i = 0, l = owners.length; i < l; i++) {
// Force the parent component to update in turn
(owners[i]).$forceUpdate();
}
};
var resolve = once(function (res) {
factory.resolved = ensureCtor(res, baseCtor);
// If it is asynchronous, the parent component is forced to update at resolve.
if(! sync) {
forceRender(true);
} else {
owners.length = 0;
}
});
var reject = once(function (reason) {/ /... });
// Execute the factory function of the asynchronous component
var res = factory(resolve, reject);
Copy the code
Similarly, if there is a new asynchronously loaded component, it will not wait for the parent component to update.
Ok, that’s all I want to share today. I just want to make sure that the parent component life cycle is executed in the order in which components are nested.
The resources
[1]
Life cycle here: https://cn.vuejs.org/v2/guide/instance.html#%E7%94%9F%E5%91%BD%E5%91%A8%E6%9C%9F%E5%9B%BE%E7%A4%BA
This article is formatted using MDNICE