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节点。
