In the React15 lifecycle, we introduced the React15 lifecycle from the mount, update, and uninstall phases. In this article, we will introduce the life cycle of React16 through the same three phases and compare React 15 and React16 versions.

React 16 Is based on React 16.3.

Mounting Stage (Mounting) : Initial rendering of components

React 16.3 / componentWillMount getDerivedStateFromProps/componentWillMount In other words, getDerivedStateFromProps is deprecated for componentWillMount.

Know getDerivedStateFromProps

How this lifecycle is invoked:

static getDerivedStateFromProps(props, state)
Copy the code

This lifecycle is called before the Render method is called, and is called both during the initial mount and for subsequent updates.

The following is an example:

import React from "react"; export default class App extends React.Component { static getDerivedStateFromProps(state, props) { console.log('getDerivedStateFromProps()'); } render() { console.log('render()'); return ( <div> <h1>Hello World</h1> </div> ); }}Copy the code

In use, there are three points to pay attention to.

First, getDerivedStateFromProps is a static method. Static methods do not depend on component instances, so there is no way to get this internally. An error is reported if this is forcibly fetched, as shown in the following figure:

Second, the method can accept two arguments: props and state. They represent props and state from the parent component, respectively.

Third, the method should return an object to update state, and if null is returned, nothing is updated. React will issue a warning if nothing is returned, as shown below:

Like setState, this method does not update state “overridden”, but rather targeted to a property.

Modify our sample code as follows:

import React from "react"; export default class App extends React.Component { state = { message: "Hello World", }; static getDerivedStateFromProps(state, props) { console.log("getDerivedStateFromProps()"); return { name: "chen", }; } componentDidMount() { console.log("state", this.state); } render() { console.log("render()"); return ( <div> <h1>Hello World</h1> </div> ); }}Copy the code

The output is as follows:

For more information about getDerivedStateFromProps(), visit the official documentation.

Updating: Updating of components

A life cycle has also been added at this stage: getSnapshotBeforeUpdate.

Know getSnapshotBeforeUpdate

How this lifecycle is invoked:

getSnapshotBeforeUpdate(prevProps, prevState)
Copy the code

This life cycle is called before the last render output (submitted to a DOM node), that is, after Render and before componentDidUpdata. It allows us to get the real DOM before and after the component update and the state&props information before and after the update.

It is worth noting that the value returned by getSnapshotBeforeUpdate is the third parameter to componentDidUpdate.

componentDidUpdate(prevProps, prevState, snapShot)
Copy the code

For an example and more information about getSanpshotBeforeUpdate(), visit the official documentation

Unmounting: Components are unmounted

React 16.3 has the same uninstall phase as React 15, which won’t be described here.

Obsolete and new life cycles

By comparing React 16.3 to React 15, we can see which life cycles are outdated and which life cycles are added.

Outdated life cycles

Outdated component life cycles often lead to unsafe coding practices, as follows:

  • componentWillMount
  • componentWillReceiveProps
  • componentWillUpdate

These lifecycle methods are often misunderstood and abused, and they can be even more harmful in asynchronous rendering. React officially adds the “UNSAFE_” prefix to these life cycles. (Unsafe does not refer to security, but rather to the fact that these lifecyclesare more likely to be buggy in future versions of React, especially after asynchronous rendering is enabled)

New life cycle

  • getDerivedStateFromProps
  • getSnapshotBeforeUpdate

GetDerivedStateFromProps and componentDidUpdate together, can be outdated componentWillReceiveProps cover all cases.

GetSnapshotBeforeUpdate together with componentDidUpdate overrides all use cases of obsolete componentWilUpdate.

React 16 Why did you change the life cycle?

Fiber architecture brief analysis

Fiber is a rewrite of the React core algorithm. All we need to know about Fiber for now is that Fiber turns React 15’s recursive, uninterruptible updates into asynchronous, interruptible updates.

Before explaining the difference between the two, let’s take a look at two graphs:

React 15:

React 16:

Before React 16, updates were executed recursively, so once they started, they couldn’t be interrupted halfway through. When the hierarchy is very deep, rendering times are very long, and the page runs the risk of stalling or even stalling, affecting the user experience.

React 16 introduced Fiber architecture to solve this problem. Instead of “going back and forth”, updates can be interrupted, which is called asynchronous rendering.

Look at the life cycle in a different way

An important feature of the Fiber architecture is asynchronous rendering that can be interrupted. The React 16 lifecycle is divided into render and COMMIT phases depending on whether it can be interrupted, and the COMMIT phase is subdivided into pre-commit and COMMIT phases. The life cycle of each stage is shown in the figure below:

Characteristics of the three stages:

  • Render phase: Pure and free of side effects, may be paused, halted, or restarted by React.
  • Pre-commit phase: DOM can be read.
  • Commit phase: You can use DOM, run side effects, and schedule updates.

In general, the Render phase can be interrupted during execution, whereas the COMMIT phase is always executed synchronously.

The Render phase can be paused, suspended, or restarted by React, so the life cycle of this phase is likely to be repeated.

You may notice that the outdated life cycles mentioned above are all in the Render phase, so they can be repeated. And we like to write a lot of “componentWill” in these life cycles, including but not limited to:

  • setState()
  • Making an asynchronous request
  • Manipulating the real DOM

These operations are more likely to cause major bugs in asynchronous rendering, which is why React officially sets these lives to “UNSAFE_”.

conclusion

In this article, we compare React 15 and React 16.3 in three phases, identify the obsolete and new life cycles, and introduce the use of new life cycles.

We also analyzed the changes from React 15 to React 16.3 in terms of architecture, and gained a new understanding of the changes in the React lifecycle and the reasons behind them.

Overall, the main reason React 16 changed its lifecycle was to accommodate the asynchronous rendering mechanism introduced by the Fiber architecture. In the React release, mandatory best practices are implemented for the chronically abused and misunderstood parts of the lifecycle, ensuring the security and correctness of data and views in Fiber architecture and making the behavior of the lifecycle approach more fragmented, controllable, and predictable. (From React.)

reference

  • Updates to asynchronous rendering
  • The projects. Wojtekmaj. Pl/react – lifec…
  • React in plain English — Xiu Yan