To understand the evolution of the life cycle of ReactNative

preface

As we all know, every application development framework has its corresponding life cycle function. ReactNative is developed based on React, so its life cycle function is as inseparable as React. Why is the article titled “Evolution of life Cycle”? React 15 and React 16 have been optimized for the lifecycle function. What are the changes? Let’s find out with this article.

React 15 Life cycle function

The following diagram is a typical React 15 lifecycle function flow diagram that most of us are aware of.React 15 lifecycle functions are as follows:

constructor()

componentWillReceiveProps()

shouldComponentUpdate()

componentWillMount()

componentWillUpdate()

componentDidUpdate()

componentDidMount()

render()

componentWillUnmount()

Copy the code

Mounting Phase: The component initializes the rendering

The initial rendering phase mainly involves the following lifecycle functions:

constructor()

componentWillMount()

render()

componentDidMount()

Copy the code

Constructor () This function is called only once during component initialization and is typically used in development primarily to initialize state data. ComponentWillMount (), componentDidMount() is called only once during component initialization, and componentWillMount() is called before render() is executed. Some students will make network requests in this function. What are the risks? The Render () method is then triggered to render the page, but it doesn’t manipulate the actual DOM, just returns the page to be rendered. The actual processing is done by the reactdom.render method in the page hanging phase. The componentDidMount() function is called when the real DOM has been mounted, and is usually used in development for network requests, message listeners, and so on to manipulate the real DOM.

Updating stage: Component updates

Component updates are divided into two types: updates triggered by the parent component’s update, and updates triggered by the component’s own call to this.setState(). The following lifecycle functions are involved in component update:

componentWillReceiveProps()

shouldComponentUpdate()

componentWillUpdate()

render()

componentDidUpdate()

Copy the code

First look at the componentWillReceiveProps (nextProps), the function parameters of nextProps said to accept the new props, and can be used to this. Comparing props, see whether to change.

Please note that if the parent components in the component rendering, even props has not changed, also this method is called (componentWillReceiveProps). If you only want to process changes, be sure to compare the current value to the changed value. —— React Official document

Key point: namely componentWillReceiveProps () function is not props change triggers, but because the parent component triggered update.

ShouldComponentUpdate (nextProps, nextState) is used when the component’s props are changed. This function returns a value that determines whether to render the component again. It will render again; In actual development work, we usually compare the parameters in the function to determine whether the business logic needs to be rerender. This is one of the performance optimizations React provides.

ComponentWillUpdate () and componentDidUpdate() are triggered around Render, corresponding to componentWillMount() and componentDidMount(). ComponentDidUpdate is triggered after the component has been updated to manipulate the real DOM.

Unmounting: Components are unmounted

This phase is simpler, with only one lifecycle function:

componentWillUnmount()

Copy the code

The componentWillUnmount() function is triggered before component uninstallation and destruction, and we usually do things like clear timers, cancel network requests, or clear subscriptions created in componentDidMount().

Evolution: React 16 lifecycle functions

We reviewed the React 15 lifecycle functions. What are the updates and improvements to React 16? The lifecycle of version 16.3 and version 16.4 is slightly different. Let’s start with the flow chart of version 16.3The React 16.3 Lifecycle The designed lifecycle functions are as follows:

constructor()

getDerivedStateFromProps()

getSnapshotBeforeUpdate()

shouldComponentUpdate()

componentDidUpdate()

componentDidMount()

render()

componentWillUnmount()

Copy the code

Mounting Phase: Component initialization phase (Mounting)

The lifecycle functions involved in the Mounting phase of React 16 are as follows:

constructor()

getDerivedStateFromProps()

componentDidMount()

render()

Copy the code

React 16 has more getDerivedStateFromProps() and less componentWillMount() during initialization than React 15. Is getDerivedStateFromProps() used to replace componentWillMount()? So let’s first look at this function

static getDerivedStateFromProps(props, state)

Copy the code

This is a static function and returns an object to update the state. If null is returned, the state is not updated. There are three key important things to know about this function. First, this is a static function, so you can’t access an instance of class in this function, which means you can’t use this to get data from this. Props. The second function takes two parameters,props, which is props passed by the parent component, and state, which is its own state. The third function requires a return value in object format, because state needs to be updated based on the returned data. If state is not updated, null is returned, and if nothing is returned, a warning is received, or the function is not restarted at all.

Updating stage: Component update stage

The functions involved in the update phase are as follows:

getDerivedStateFromProps()

shouldComponentUpdate()

render()

getSnapshotBeforeUpdate()

componentDidUpdate()

Copy the code

In the update phase, 16.3 and 16.4 are slightly different. Look at the flow chartBy comparing the flow charts of 16.3 and 16.4, we can see that the change is the trigger time of getDerivedStateFromProps(). The main changes are as follows: In React 16.4, getDerivedStateFromProps() is triggered when the parent component updates the props, the component itself calls the setState() function, and the forceUpdate() function is executed 16.3 Only parent component updates are triggered during the update phase.

Contrast the React 15, we found that the React less 16 version componentWillReceiveProps () and componentWillUpdate (), Added getDerivedStateFromProps() and getSnapshotBeforeUpdate().

We know the React 15 parent components updated triggers componentWillReceiveProps () function, and its own setState not trigger, In React 16, any updates to components trigger the getDerivedStateFromProps() function. Why? The explanation is presented in this paper, the React for getDerivedStateFromProps:

This new life cycle covers with componentDidUpdate outdated componentWillReceiveProps all use cases.

Can be seen that this new function is not only a simple alternative componentWillReceiveProps, its method is the static by definition, namely inside the method can access this, then it can avoid the wrong operation, such as the use of this. The fetch request for network, Using this.setsate to render causes an infinite loop. So getDerivedStateFromProps exists for only one purpose: to let the component update state when the props changes. As for the use of this function, official advice is also given:

Note: old componentWillReceiveProps and new getDerivedStateFromProps method can give the complexity of components significantly increased. This often leads to bugs. Consider simple alternatives to deriving state to make components predictable and maintainable.

GetSnapshotBeforeUpdate, React

Along with componentDidUpdate, this new life cycle covers all use cases for obsolete componentWillUpdate.

getSnapshotBeforeUpdate(prevProps, prevState)

Copy the code

GetSnapshotBeforeUpdate () is called before the last render output (submitted to the DOM node). It enables the component to capture some information (for example, scroll position) from the DOM before changes are made. Any return value for this life cycle is passed as an argument to componentDidUpdate(). In this function, you can get the actual DOM before the update and the latest props and state after the update. Finally, look at the componentDidUpdate function

componentDidUpdate(prevProps, prevState, snapshot)

Copy the code

If the component implements the getSnapshotBeforeUpdate() life cycle (not often), its return value is passed as the third parameter to componentDidUpdate(), the “snapshot” parameter. Otherwise, the parameter will be undefined.

Unmounting: Components are unmounted

React 16 is the same as React 15 in the uninstall phase, and only one lifecycle function is involved:

componentWillUnmount()

Copy the code

SetState () should not be called in componentWillUnmount() because the component will never be re-rendered. Once a component instance is unmounted, it will never be mounted again.

Life cycle evolution

The reason the React lifecycle changed and improved was because the React project rewrote React using the core architecture that became “Fiber.” Fiber changed React 15’s synchronous rendering to asynchronous rendering, avoiding blocking the React main thread. Before React 16, we used setState to update the component. React generates a new virtual DOM and then updates the real DOM by diff comparison with the previous DOM. This is a recursive process of simultaneous rendering, like walking a staircase.If the layout of the page is complex and deeply nested, then the recursive call time will be very long, then the main thread will be occupied by JS, any interaction, layout, rendering will stop, and the picture presented to the user is very slow. This problem was solved with Fiber refactoring, which sliced up long update tasks into smaller ones. After performing a small task, swap the main thread back to see if there is a higher priority task to deal with, thus avoiding the UI blocking problem caused by synchronous updates. After slicing with Fiber, the asynchronous rendering task becomes interruptible, and the execution becomes as follows:

The story behind using Fiber

After React 16, the following lifecycle functions were flagged as unsafe,

componentWillMount

componentWillReceiveProps

componentWillUpdate

Copy the code

These lifecycle functions are now prefixed with “UNSAFE_” to look like this:

UNSAFE_componentWillMount,

UNSAFE_componentWillReceiveProps 

UNSAFE_componentWillUpdate

Copy the code

After Fiber reconstruction, rendering becomes asynchronous. By checking the new life cycle map, these methods are in the original render stage, that is, repeated calls will occur, for example, improper use of setState will cause repeated rendering loop.

conclusion

In general, the evolution of the React lifecycle is in the service of Fiber architecture. Fiber has asynchronous rendering mechanism, which makes the lifecycle more pure and controllable, and also reduces unnecessary bugs caused by non-standard code writing.

Think the article is good, give me a thumbs up, pay attention to bai! Technical exchange can pay attention to the public number [Jun Wei said], can leave a message to add my friends to discuss!