React 核心团队成员解释“代数效应与 React”-react代数效应

React核心团队成员Sebastian Markbåge[1]（React Hooks的发明者）曾说：我们在React中做的就是践行代数效应（Algebraic Effects）。

那么，代数效应是什么呢？它和React有什么关系呢。

什么是代数效应

代数效应是函数式编程中的一个概念，用于将副作用从函数调用中分离。

接下来我们用虚构的语法来解释。

假设我们有一个函数getTotalPicNum，传入2个用户名称后，分别查找该用户在平台保存的图片数量，最后将图片数量相加后返回。

function getTotalPicNum(user1, user2) { 
 
  const num1 = getPicNum(user1); 
 
  const num2 = getPicNum(user2); 
 
  return picNum1 + picNum2; 
 
}

在getTotalPicNum中，我们不关注getPicNum的实现，只在乎“获取到两个数字后将他们相加的结果返回”这一过程。

接下来我们来实现getPicNum。

"用户在平台保存的图片数量"是保存在服务器中的。所以，为了获取该值，我们需要发起异步请求。

为了尽量保持getTotalPicNum的调用方式不变，我们首先想到了使用async await：

async function getTotalPicNum(user1, user2) { 
 
  const num1 = await getPicNum(user1); 
 
  const num2 = await getPicNum(user2); 
 
  return picNum1 + picNum2; 
 
}

但是，async await是有传染性的 —— 当一个函数变为async后，这意味着调用他的函数也需要是async，这破坏了getTotalPicNum的同步特性。

有没有什么办法能保持getTotalPicNum保持现有调用方式不变的情况下实现异步请求呢？

没有。不过我们可以虚构一个。

我们虚构一个类似try...catch的语法 —— try...handle与两个操作符perform、resume。

function getPicNum(name) { 
 
  const picNum = perform name; 
 
  return picNum; 
 
} 
 
try { 
 
  getTotalPicNum('kaSong', 'xiaoMing'); 
 
} handle (who) { 
 
  switch (who) { 
 
    case 'kaSong': 
 
      resume with 230; 
 
    case 'xiaoMing': 
 
      resume with 122; 
 
    default: 
 
      resume with 0; 
 
  } 
 
}

当执行到getTotalPicNum内部的getPicNum方法时，会执行perform name。

此时函数调用栈会从getPicNum方法内跳出，被最近一个try...handle捕获。类似throw Error后被最近一个try...catch捕获。

类似throw Error后Error会作为catch的参数，perform name后name会作为handle的参数。

与try...catch最大的不同在于：当Error被catch捕获后，之前的调用栈就销毁了。而handle执行resume后会回到之前perform的调用栈。

对于case 'kaSong'，执行完resume with 230;后调用栈会回到getPicNum，此时picNum === 230

再次申明，try...handle的语法是虚构的，只是为了演示代数效应的思想。

总结一下：代数效应能够将副作用（例子中为请求图片数量）从函数逻辑中分离，使函数关注点保持纯粹。

并且，从例子中可以看出，perform resume不需要区分同步异步。

代数效应在React中的应用

那么代数效应与React有什么关系呢？最明显的例子就是Hooks。

对于类似useState、useReducer、useRef这样的Hook，我们不需要关注FunctionComponent的state在Hook中是如何保存的，React会为我们处理。

我们只需要假设useState返回的是我们想要的state，并编写业务逻辑就行。

function App() { 
 
  const [num, updateNum] = useState(0); 
 
   
 
  return ( 
 
    <button onClick={() => updateNum(num => num + 1)}>{num}</button>   
 
  ) 
 
}

如果这个例子还不够明显，可以看看官方的Suspense Demo[2]

在Demo中ProfileDetails用于展示用户名称。而用户名称是异步请求的。

但是Demo中完全是同步的写法。

function ProfileDetails() { 
 
  const user = resource.user.read(); 
 
  return <h1>{user.name}</h1>; 
 
}

代数效应与Generator

从React15到React16，协调器（Reconciler）重构的一大目的是：将老的同步更新的架构变为异步可中断更新。

异步可中断更新可以理解为：更新在执行过程中可能会被打断（浏览器时间分片用尽或有更高优任务插队），当可以继续执行时恢复之前执行的中间状态。

这就是代数效应中try...handle的作用。

其实，浏览器原生就支持类似的实现，这就是Generator。

但是Generator的一些缺陷使React团队放弃了他：

类似async，Generator也是传染性的，使用了Generator则上下文的其他函数也需要作出改变。这样心智负担比较重。

Generator执行的中间状态是上下文关联的。

考虑如下例子：

function* doWork(A, B, C) { 
 
  var x = doExpensiveWorkA(A); 
 
  yield; 
 
  var y = x + doExpensiveWorkB(B); 
 
  yield; 
 
  var z = y + doExpensiveWorkC(C); 
 
  return z; 
 
}

每当浏览器有空闲时间都会依次执行其中一个doExpensiveWork，当时间用尽则会中断，当再次恢复时会从中断位置继续执行。

只考虑“单一优先级任务的中断与继续”情况下Generator可以很好的实现异步可中断更新。

但是当我们考虑“高优先级任务插队”的情况，如果此时已经完成doExpensiveWorkA与doExpensiveWorkB计算出x与y。

此时B组件接收到一个高优更新，由于Generator执行的中间状态是上下文关联的的，所以重新计算y时无法复用之前已经计算出的x，需要重新计算。

如果通过全局变量保存之前执行的中间状态，又会引入新的复杂度。

更详细的解释可以参考这个issue[3]

基于这些原因，React没有采用Generator实现协调器。

代数效应与Fiber

Fiber并不是计算机术语中的新名词，他的中文翻译叫做纤程，与进程（Process）、线程（Thread）、协程（Coroutine）同为程序执行过程。

在很多文章中将纤程理解为协程的一种实现。在JS中，协程的实现便是Generator。

所以，我们可以将纤程(Fiber)、协程(Generator)理解为代数效应思想在JS中的体现。

React Fiber可以理解为：

React内部实现的一套状态更新机制。支持任务不同优先级，可中断与恢复，并且恢复后可以复用之前的中间状态。

其中每个任务更新单元为React Element对应的Fiber节点。