React新特性为啥产出这么慢?江郎才尽啦?

开发 前端
发展到今天,6年时间,不仅框架本身没有没落,框架所使用的JSX语法甚至已经成了前端领域事实上的通用DSL。在这激荡的6年中,虽然前端领域天翻地覆,但是React的主要API和方法改动却很少。

[[397974]]

 有人曾说:每过一年,前端的入行难度提升一倍。

难度提升很大程度源于前端技术飞快的更新导致新技术加速出现,老技术加速淘汰。

但是,这里有个奇葩:React。

作为前端领域最广为人知的技术之一,React2015年被「Jordan Walke」创造出来。

[[397975]]

发展到今天,6年时间,不仅框架本身没有没落,框架所使用的JSX语法甚至已经成了前端领域事实上的通用DSL。

在这激荡的6年中,虽然前端领域天翻地覆,但是React的主要API和方法改动却很少。

这一方面展示了React核心团队卓越的前瞻性和框架设计能力。

另一方面,不禁让人质疑,React新特性为啥产出这么慢?江郎才尽啦?

尤其是前段时间,React17经过了2年的迭代终于发出稳定版,但是却没有新增特性。

这个问题的标准答案恐怕只有React团队成员才知道。

不过,我们可以从源码feature的迭代过程来管中窥豹。

新特性如何产出

如果把React比喻为一艘战舰,他对外提供了「开炮」、「航行」等能力。

开发者就像战舰的船员,使用这些能力操纵战舰的行为。

[[397976]]

当React这艘战舰需要开发新的能力,比如「高速航行」

「航行」依赖于战舰的整套动力系统。

那么,一定会有大量动力系统的改造工作需要先行完成。

前期改造工作需要做多长时间呢?

纵观React历史,将组件树的render从同步(Legacy Mode)变为可中断的异步(Concurrent Mode),花了2年。

这其中包括:

  • 将底层架构从递归(Stack Reconciler)变为遍历(Fiber Reconciler)
  • 实现调度器(Scheduler)
  • 实现调度算法(ExpirationTime,现在改为Lanes)

Fiber是如此出名,很多前端多听说过。

今天,我们挑一个不出名的底层feature —— effect list。

让我们看看他的迭代过程。

为什么选择effect list

effect list是React源码commit阶段的一个特性,选择他的迭代历程讲解是因为:

  1. 他是源码内部的feature,对开发者不可知
  2. 表面上看起来这是一个不大的改动
  3. 他的改动是为了上层新特性而做的底层调整

什么是effect list

React内部工作大体可以分为3个阶段:

  1. 调度更新
  2. 决定什么组件需要更新
  3. 更新组件

那么第三步如何知道要更新哪些组件呢?靠effect list。

如果将React Fiber树比喻为圣诞树,那么每个Fiber节点就是圣诞树上的挂件。

其中需要更新的节点就是亮的彩灯。

如何找到亮的彩灯(需要更新的节点)呢?

从圣诞树顶向下一个挂件一个挂件找么(从根节点依次向下遍历)?

可行,但是效率太低。

为此,React的做法是:将需要更新的节点连接形成一条单链表。

查找时,只需要遍历这条单链表就行。就像圣诞树上的彩灯带一样。

[[397977]]

这条彩灯带(单链表)就是effect list。

计划赶不上变化

effect list在React源码中辛勤工作了2年。

但是,未来React新特性需要底层架构支持遍历整棵Fiber树。

看我刚才的介绍,是不是去掉effect list,改为从根节点遍历就行?

感觉这需求,我上我也行(并不是)。

[[397978]]

于是,经过一番内部讨论后,2020年7月7日,「bvaughn」老哥提了effect list改造相关的第一个PREffects list refactor #19261

  • 移除了effect list相关变量(firstEffect,lastEffect, nextEffect)
  • 新增了subtreeTag标记变量用于优化遍历Fiber树的性能

感觉胜利在望,7月16日,老哥又继续提了PR Effects list refactor continued: passive effects traversal #19374

[[397979]]

增加了对useEffect回调函数执行流程的改动(没错,useEffect回调函数的执行也属于effect list的一个节点)

感觉胜利在望,OKR要到手了呢~

经过漫长的测试、回归,到了11月,Andrew发现effect list的重构造成某个指标下降,但由于React源码运行流程太过复杂,一时半会也查不出原因。

只能先回滚了,见PR Reset new fork to old fork #20254

今年1月中旬,终于验证这个特性没有问题,又重新改回去,见PR Re-land refactored implementation of layout phase in new fork #20595

更难受的是,React源码中为了区分新旧特性,每个文件都分为.new和.old两个版本,每次劳动量都是双份。

[[397980]]

总结

兜兜转转,核心团队2个成员从7月忙到第二年1月,每次PR,还需要其他成员review代码。

终于将这个特性合并到master。

想想Andrew走在街上被React爱好者认出来,亲切询问:嗨,Andrew,下半年你忙啥了?

Andrew:

[[397981]]

从这个小feature的迭代历程,你感受到React新特性迭代慢的原因了么?

 

责任编辑:姜华 来源: 魔术师卡颂
相关推荐

2018-08-02 16:17:34

Python 开发编程语言

2020-08-03 09:40:39

Python编程语言Instagram

2010-05-28 09:06:09

Novell

2021-11-01 19:49:55

React组件模式

2021-06-22 07:45:57

React18startTransiReact

2018-08-16 08:03:21

Python语言解释器

2021-06-22 07:30:07

React18Automatic b自动批处理

2024-04-28 09:01:06

React 19更新前端

2021-03-01 11:22:19

云网融合运营商上云

2021-02-23 15:11:21

曙光

2020-03-20 10:25:41

React-Routev6前端

2017-03-29 20:30:03

2022-04-25 09:48:31

数据科学岗位离职

2020-09-16 10:50:16

C++14语言代码

2016-12-28 11:28:19

.NET反射

2021-05-29 06:23:47

webpack esbuild

2020-08-14 09:11:29

RedisQPS数据库

2009-06-03 16:10:34

OpenSolaris

2019-02-25 08:28:53

2019-05-28 14:55:41

Python人工智能Java
点赞
收藏

51CTO技术栈公众号