杭州做seo的公司,南昌seo招聘,应届生出来做网站还是做报纸好,宁波模板建站哪家好前言 自从React发布Fiber之后#xff0c;更新速度日新月异#xff0c;而生命周期也随之改变#xff0c;虽然原有的一些生命周期函数面临废弃#xff0c;但理解其背后更新的机制也是一种学习 在这里根据官方文档以及社区上其他优秀的文章进行一个对于生命周期的总结#xf…前言 自从React发布Fiber之后更新速度日新月异而生命周期也随之改变虽然原有的一些生命周期函数面临废弃但理解其背后更新的机制也是一种学习 在这里根据官方文档以及社区上其他优秀的文章进行一个对于生命周期的总结大致上分为以下三个模块 新老生命周期的区别为什么数据获取要在componentDidMount中进行为什么要改变生命周期新老生命周期的区别 新的生命周期增加了static getDerivedStateFromProps()以及getSnapshotBeforeUpdate()废弃了原有的componentWillMount()、componentWillUpdate()以及componentWillReceiveProps() 分别如以下图 原生命周期 新生命周期图引用自React v16.3之后的组件生命周期函数 为什么数据获取要在componentDidMount中进行 作者一开始也喜欢在React的willMount函数中进行异步获取数据认为这可以减少白屏的时间后来发现其实应该在didMount中进行。 首先分析一下两者请求数据的区别 componentWillMount获取数据 执行willMount函数等待数据返回执行render函数执行didMount函数数据返回 执行renderdidMount获取数据 执行willMount函数执行render函数执行didMount函数 等待数据返回数据返回 执行render很明显在willMount中获取数据可以节省时间render函数和didMount函数的执行时间但是为什么我们还要在didMount中获取数据 如果使用服务端渲染的话willMount会在服务端和客户端各自执行一次这会导致请求两次接受不了~而didMount只会在客户端进行在Fiber之后 由于任务可中断willMount可能会被执行多次willMount会被废弃目前被标记为不安全节省的时间非常少跟其他的延迟情况相比这个优化可以使用九牛一毛的形容为了这么一点时间而一直不跟进技术的发展得不偿失并且render函数是肯定比异步数据到达先执行白屏时间并不能减少关于第一点如果你想在服务端渲染时先完成数据的展示再一次性给用户官方的推荐做法是用constructor代替willMount 为什么要改变生命周期 从上面的生命周期的图中可以看出被废弃的三个函数都是在render之前因为fiber的出现很可能因为高优先级任务的出现而打断现有任务导致它们会被执行多次 另外的一个原因则是React想约束使用者好的框架能够让人不得已写出容易维护和扩展的代码这一点又是从何谈起我们可以从新增加以及即将废弃的生命周期分析入手 componentWillMoun 首先这个函数的功能完全可以使用componentDidMount和constructor来代替异步获取的数据的情况上面已经说明了而如果抛去异步获取数据其余的即是初始化而已这些功能都可以在constructor中执行除此之外如果我们在willMount中订阅事件但在服务端这并不会执行willUnMount事件也就是说服务端会导致内存泄漏 所以componentWillMount完全可以不使用但使用者有时候难免因为各种各样的情况如作者犯浑在componentWillMount中做一些操作那么React为了约束开发者干脆就抛掉了这个API componentWillReceiveProps 在老版本的 React 中如果组件自身的某个 state 跟其 props 密切相关的话一直都没有一种很优雅的处理方式去更新 state而是需要在 componentWillReceiveProps 中判断前后两个 props 是否相同如果不同再将新的 props 更新到相应的 state 上去。这样做一来会破坏 state 数据的单一数据源导致组件状态变得不可预测另一方面也会增加组件的重绘次数。类似的业务需求也有很多如一个可以横向滑动的列表当前高亮的 Tab 显然隶属于列表自身的状态但很多情况下业务需求会要求从外部跳转至列表时根据传入的某个值直接定位到某个 Tab。 本段引用自React v16.3 版本新生命周期函数浅析及升级方案 为了解决这些问题React引入了第一个新的生命周期 static getDerivedStateFromProps 可以先看一下两者在使用上的区别 原有的代码 新的代码 这样看似乎没有什么改变特别是当我们把this,tabChange也放在didUpdate中执行时正确做法完全没有不同但这也是我们一开始想说的React通过API来约束开发者写出更好的代码而新的使用方法有以下的优点 getDSFP是静态方法在这里不能使用this也就是一个纯函数开发者不能写出副作用的代码开发者只能通过prevState而不是prevProps来做对比保证了state和props之间的简单关系以及不需要处理第一次渲染时prevProps为空的情况基于第一点将状态变化setState和昂贵操作tabChange区分开更加便于 render 和 commit 阶段操作或者说优化。componentWillUpdate 与 componentWillReceiveProps 类似许多开发者也会在 componentWillUpdate 中根据 props 的变化去触发一些回调。但不论是 componentWillReceiveProps 还是 componentWillUpdate都有可能在一次更新中被调用多次也就是说写在这里的回调函数也有可能会被调用多次这显然是不可取的。与 componentDidMount 类似componentDidUpdate 也不存在这样的问题一次更新中 componentDidUpdate 只会被调用一次所以将原先写在 componentWillUpdate 中的回调迁移至 componentDidUpdate 就可以解决这个问题。本段引用自React v16.3 版本新生命周期函数浅析及升级方案 另外一种情况则是我们需要获取DOM元素状态但是由于在fiber中render可打断可能在willMount中获取到的元素状态很可能与实际需要的不同这个通常可以使用第二个新增的生命函数的解决 getSnapshotBeforeUpdate getSnapshotBeforeUpdate(prevProps, prevState) // 返回的值作为componentDidUpdate的第三个参数
复制代码与willMount不同的是 getSnapshotBeforeUpdate会在最终确定的render执行之前执行也就是能保证其获取到的元素状态与didUpdate中获取到的元素状态相同这里官方提供了一段参考代码 总结 随着React Fiber的落地许多功能都将开始改变但本质上是换汤不换药很多时候都是React为了开发者写出更好的代码而做的改变当然这也是React的厉害之处通过框架来约束开发者
