A, the react
React lifecycle
Including: data initialization, creation, mounting, update, and destruction
React Lifecycle execution sequence in a project
constructor() => componentWillMount() => render() => componentDidMount()
When the update is executed directly the following is executed:
componentWillReceiveProps (nextProps) => shouldComponentUpdate(nextProps,nextState) => componentWillUpdate (nextProps,nextState) => render() => componentDidUpdate(prevProps,prevState)
Closing the page components are eventually destroyed: componentWillUnmount ()
React new lifecycle:
-
getDerivedStateFromProps(nextProps, prevState)
-
getSnapshotBeforeUpdate(prevProps, prevState)
A few points are emphasized:
-
The React data is initialized by constructor(), which accepts two parameters: props and context. When you want to use these two parameters inside a function, you need to pass them in with super(). Note: Whenever you use constructor() you must write super(), otherwise this will point to an error.
-
Render () inserts the JSX-generated DOM structure and React generates a virtual DOM tree. At each component update, React uses its diff algorithm to compare the old and new DOM trees before and after the update. After the comparison, the smallest dom nodes with differences are found and re-rendered.
GetDerivedStateFromProps () instead of componentWillReceiveProps ()
In componentWillReceiveProps, tend to do the following two things:
- Update the state according to props
- Trigger some callback, such as an animation or a page jump.
ComponentWillReceiveProps faults:
- Can break a single source of state data, causing component state to become unpredictable
- It also increases the number of redraws of components
- Update the state and trigger callbacks are carried out in componentWillReceiveProps
GetDerivedStateFromProps advantages:
-
GetDerivedStateFromProps disallows the component from accessing this. Props, forcing the developer to compare the values of nextProps and prevState. To make sure that when developers use the getDerivedStateFromProps lifecycle function, they are updating the component’s state based on the current props, rather than doing something else that makes the component’s state more unpredictable.
-
The update state is in getDerivedStateFromProps, and the trigger callback is in componentDidUpdate to make the overall update logic of the component clearer
// before
componentWillReceiveProps(nextProps) {
if(nextProps.isSuccess ! = =this.props.isSuccess) {
this.setState({
isLogin: nextProps.isSuccess,
});
}
if (nextProps.isSuccess) {
this.close(); }}// after
static getDerivedStateFromProps(nextProps, prevState) {
if(nextProps.isSuccess ! == prevState.isSuccess) {return {
isLogin: nextProps.isSuccess,
};
}
return null;
}
componentDidUpdate(prevProps, prevState) {
if(! prevState.isSuccess &&this.props.isSuccess) {
this.close(); }}Copy the code
GetSnapshotBeforeUpdate () instead of componentWillUpdate ()
A common use case for componentWillUpdate is to read the current state of a DOM element and process it in componentDidUpdate
Disadvantages of componentWillUpdate:
- When React turns on asynchronous render mode, the DOM element states read in the Render phase are not always the same as those read in the COMMIT phase
It is not safe to use the DOM element states read in componentWillUpdate for componentDidUpdate, since the values may be invalid
.
Advantages of getSnapshotBeforeUpdate:
GetSnapshotBeforeUpdate will be called before final render
That is, the DOM element states read in getSnapshotBeforeUpdate are guaranteed to be the same as those in componentDidUpdate.- Any values returned by this life cycle are passed as arguments to componentDidUpdate()
Second, the vue
Vue life cycle
Vue each component is independent, and each component has its own life cycle.
Including: data initialization, creation, mounting, update, and destruction
The order in which the VUE lifecycle is executed in a project
beforeCeate() => data() => created() => beforeMount() => mounted()
BeforeUpdate => updated after created is inserted
Closing page components will eventually be destroyed: beforeDestroy() => Destroyed ()
A few points are emphasized:
- BeforeCeate is called before the event and lifecycle hooks are initialized
- Initialization of data is done before creation with data Observer
https://github.com/vuejs/vue/blob/dev/src/core/instance/init.js
initLifecycle(vm)
initEvents(vm)
initRender(vm)
callHook(vm, 'beforeCreate')
initInjections(vm) // resolve injections before data/props
initState(vm)
initProvide(vm) // resolve provide after data/props
callHook(vm, 'created')
Copy the code
Running order of built-in method properties in VUE (Methods, computed, data, Watch, props)
Props => methods =>data => computed => watch
https://github.com/vuejs/vue/blob/dev/src/core/instance/state.js export function initState (vm: Component) { vm._watchers = [] const opts = vm.$options if (opts.props) initProps(vm, opts.props) if (opts.methods) initMethods(vm, opts.methods) if (opts.data) { initData(vm) } else { observe(vm._data = {}, true /* asRootData */) } if (opts.computed) initComputed(vm, opts.computed) if (opts.watch && opts.watch ! == nativeWatch) { initWatch(vm, opts.watch) } }Copy the code
Some attention
- Mounted is the best place to execute asynchronous requests
$refs
Get the DOM element in$nextTick
Performed in the$refs
Direct access to child components, which may have data lag bugs, can be addressed by asynchronous callbacks
handleAsync () {
return new Promise(resolve= >{
resolve(res)
})
}
async handleShow() {
await this.handleAsync().then(res= >{
this.$refs.child.fun(res); })}Copy the code
To compare
Similarities:
- React and VUE asynchronous requests are best executed in mount functions (componentDidMount and Mounted)
- The life cycle consists of initialization, creation, mount, destruction, and update
- All dom elements are retrieved through refs
- Both require uninstallation and data destruction: setTimeout, setInterval, removeEventListener, etc
Difference:
- React uses componentDidUpdate. Vue uses Mounted
- It’s written very differently
www.jianshu.com/p/b331d0e4b…