- ubuntu12.04环境下使用kvm ioctl接口实现最简单的虚拟机
- Ubuntu 通过无线网络安装Ubuntu Server启动系统后连接无线网络的方法
- 在Ubuntu上搭建网桥的方法
- ubuntu 虚拟机上网方式及相关配置详解
CFSDN坚持开源创造价值,我们致力于搭建一个资源共享平台,让每一个IT人在这里找到属于你的精彩世界.
这篇CFSDN的博客文章以后没有 React Concurrent Mode了由作者收集整理,如果你对这篇文章有兴趣,记得点赞哟.
大家好,我卡颂.
相信很多关注React的朋友都知道Concurrent Mode,他是React渐进升级策略的产物.
即然是策略,那就有可能调整,这不,根据What happened to concurrent mode?[1],在v18中将不会有Concurrent Mode了.
本文让我们一起了解React渐进升级策略的演进过程.
可以认为采用Fiber架构前的React只支持一种优先级:同步优先级,即所有更新是“同步、不可中断”的形式.
采用Fiber架构后的React支持包括同步优先级在内的多种优先级,或者说新架构支持并发更新.
所以新架构可以模拟老架构的运行机制(即不开启并发更新).
当新架构开启并发更新后,就能使用React为了解决CPU的瓶颈、IO的瓶颈而设计的并发特性(Concurrent Feature),比如:
当前所有React版本一定属于如下情况之一:
v16、v17默认属于情况2.
之所以划分多种情况,是因为情况4的React一些行为异于情况1、2、3(比如部分以componentWill开头的生命周期函数的调用时机发生变化),也就是说开启并发更新可能造成老代码不兼容.
为了让广大开发者能够平滑过渡,React团队采用了「渐进升级」方案.
v16.3新增了StrictMode,对开发者编写的「不符合并发更新规范的代码」作出提示,逐步引导开发者写出规范代码.
此时React团队的「渐进升级」策略是:让页面中可以同时存在三种模式的应用,具体如下:
三种模式可用特性对比 。
在v17之前,大多数事件会冒泡到HTML元素,为了让同一个页面下不同应用独立,v17之后事件会冒泡到应用所在根元素.
所以v17也被称为「垫脚石」版本,他是为「开启并发更新」做铺垫的版本.
但是,根据社区的反馈,React团队意识到当前的「渐进升级」策略存在问题.
这三种模式影响的是整个应用,从Legacy升级到Blocking后,由于开启StrictMode,整个应用的「并发不兼容警告」都会上报。从这个角度看,并没有起到「渐进升级」的目的.
另一方面,开发者从新架构中获益更多是由于使用了并发特性,即然新架构支持「开关并发更新」,完全可以在使用了并发特性后再开启并发更新。这样就只需在「使用了并发特性的组件」部分启用StrictMode.
相比划分三种模式,这种以「是否使用并发特性」作为是否开启并发更新的依据,更符合「渐进升级」中「渐进」的理念.
所以在v18中,不再有三种模式,统一使用ReactDOM.createRoot(rootNode).render()创建应用。当不使用并发特性时,表现如情况3。使用并发特性后,表现如情况4.
一句话总结:v18以后只会有并发特性,不会有并发模式.
作为一个发展了8年之久的前端框架,要想推进社区完成带有breaking change的迭代升级,注定是困难的.
我们也看到了React团队在此确实付出很多心血.
想问问各位,还学得动么?
[1]What happened to concurrent mode?
https://github.com/reactwg/react-18/discussions/64 。
原文链接:https://mp.weixin.qq.com/s/hiocM5u_6SfJy5Adcck-3Q 。
最后此篇关于以后没有 React Concurrent Mode了的文章就讲到这里了,如果你想了解更多关于以后没有 React Concurrent Mode了的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。
命令 svn status 返回如下内容: ? SomeClient\BUTCHERED.docx M SomeClient\Development notes.txt ?
我是一名优秀的程序员,十分优秀!