React Supense和React 异步渲染的一点矛盾

React的Suspense功能，简单说就是让组件渲染遇到需要异步操作的时候，可以无缝地“悬停”（suspense）一下，等到这个异步操作有结果的时候，再无缝地继续下去。

这里所说的异步操作，可以分为两类：

• 异步加载代码
• 异步加载数据

很好辨认，写程序嘛，折腾的无外乎就是“代码”和“数据”这两样东西。

为什么要异步加载代码呢？

本来，代码打包成一个文件就行，但是当代码量很庞大，而且也不是所有代码都是页面加载的时候就用得上，把他们拉进唯一的打包文件，除了打包过程简单没有任何好处。所以，为了榨取性能，就要考虑把代码打包成若干文件，这样每个打包文件就可以比较小，根据需要来加载。这是一个好主意，不过让每个开发人员都实现这套机制也是够扯的，所以，React就用Suspense提供了统一的无缝的代码分割（Code Splitting）兼异步加载方法，在v16.6.0就实现了这样的Suspense功能。

大家有兴趣自己去玩，这种Suspense不是今天要讲的重点，今天要讲的是“异步加载数据”的Suspense，也就是利用Suspense来调用服务器API之类的操作。

根据React官方的路线图，利用Suspense来做数据加载，要等到今年（2019）的中期才发布，你如果看到这篇文章比较晚，可能已经发布了。

今天要说的，是Suspense做数据加载，和React v16的重头戏异步渲染有一点矛盾的地方。

在之前的Live 《深入理解React v16新功能》中我说过，从React v16开始，一个组件的生命周期可以分为两个阶段：reconciliation phase阶段和commit phase阶段。在reconciliation phase阶段的生命周期函数，因为Fiber的设计特点，可能会被打断，被打断之后，会重新被调用；而commit phase阶段一旦开始，就绝不会被打断。reconciliation phase阶段和commit phase阶段的分界线是render函数，注意，render函数本身属于reconciliation phase阶段。

举个例子，一个组件被渲染，执行到render函数里面，这时候用户突然在某个input控件里输入了什么，这时候React决定去优先处理input控件里的按键事件，就会打断这个组件的渲染过程，也就是不管render返回啥，渲染过程都就此打住，不画了，专心去处理input控件的事情去了。等到那边的事情处理完，再来渲染这个组件，但是这时候从原来位置重新开始，那肯定是不靠谱的，因为刚才的按键事件处理可能改变了一些状态，为了保证绝对靠谱，React决定……还是从头走一遍吧， 于是，重新去调getDerivedStateFromProps、shouldComponentUpdate然后调用render。

看到没哟，render之前的生命周期函数都会被调用，而且，因为这种“打断”是完全是不可预期的，所以，现在就要求在render阶段的所有生命周期函数不要做有副作用的操作。

什么叫副作用？就是纯函数不该做的操作。

什么叫纯函数？就是除了根据输入参数返回结果之外，不做任何多与事情的操作。

如果一个函数修改全局变量，那就不是一个纯函数；如果一个函数修改类实例状态，那就不是一个纯函数；如果一个函数抛出异常，那就不是一个纯函数；如果一个函数通过AJAX访问服务器API，那就不是一个纯函数。

就拿访问服务器API为例，假如reconciliation phase阶段的生命周期函数做了访问服务器API的AJAX操作，那么，很有可能产生连续对服务器的访问，因为异步渲染下reconciliation phase阶段会被打断而重复执行啊。

class Foo extends React.Component {
  shouldComoponentUpdate() {
    callAPI(); // 你只看到了一行代码，但是可能会被多次调用
    return true;
  }

  render() {
    callAPI(); // 你只看到了一行代码，但是可能会被多次调用

    return JSX;
  }
}

再说一遍，在reconciliation phase阶段的所有生命周期函数不要做有副作用的操作，这些函数必须是纯函数。

那么，现在问题来了，使用Suspense来获取数据，会不会违反者这个规定呢？

虽然Suspense这方面的API还没有确定，但是代码形式还是明确的，利用试玩版的react-cache展示一下。

import React, { Suspense } from "react";
import { unstable_createResource as createResource } from "react-cache";

// 模拟一个AJAX调用
const mockApi = () => {
  return new Promise((resolve, reject) => {
    setTimeout(() => resolve("Hello"), 1000);
  });
};

const resource = createResource(mockApi);

const Greeting = () => {
  // 注意看这里，这里依然是在render阶段，可能会被重复调用哦！
  const result = resource.read();

  return <div>{result} world</div>;
};

const SuspenseDemo = () => {
  return (
    <Suspense fallback={<div>loading...</div>}>
      <Greeting />
    </Suspense>
  );
};

export default SuspenseDemo;

这里就有意思了，使用Suspense来获取数据，既然数据是在render函数（或者像上面例子一样在函数类型组件中）使用，那么获取数据的过程肯定是在reconciliation phase阶段，但是，获取数据的过程是要调用AJAX的啊，AJAX是副作用操作，这不就和“reconciliation phase阶段不能做有副作用操作“的规定矛盾了吗？

的确有点矛盾。

React开发人员对这个的解释是这样：

简单说来，就是降低了要求，只需要reconciliation phase阶段的操作是”幂等“（indempotent）就可以了。

所谓幂等，就是一次调用和N次调用产生一样的结果。

还是举例来说吧。

// 这是纯函数，没有副作用
function foo1(a, b) {
  return a + b;
}

// 这不是纯函数，有副作用，而且不幂等
function foo2(a, b) {
  sendAjax(a + b);
  return a + b;
}

// 这不是纯函数，有副作用，但是——幂等
let called = false;
function foo3(a, b) {
  if (!called) {
    sendAjax(a + b);
  }
  called = true;
  return a + b;
}

上面的foo3这个函数，的确有副作用，但是，利用代码巧妙地防一手，只让第一次调用发出AJAX，之后的调用就不发AJAX了，这样，调用多少次，产生的效果都一样，这就是”幂等“。

幂等虽然没有纯函数那么纯，但是也足够好了，至少对于React这样无法做到”纯“的框架，这也是最好的结果。

试玩版react-cache的unstable_createResource函数，接受一个返回Promise的函数为参数，获取的Promise是会被cache住的，所以，虽然会被打断重复多次，resource.read()如果有返回结果，那么返回的结果都是一样 ，也就达到了”幂等“的效果。

这么一看，矛盾也就解决了。

总结一下，实际上我们要把”在reconciliation phase阶段的所有生命周期函数不要做有副作用的操作，这些函数必须是纯函数“这个要求改一下，改成”在reconciliation phase阶段的所有生命周期函数都应该幂等“。

虽然一说React往往都说要说“函数式编程”，但是React真的先天和崇尚纯函数的“函数式编程”有很大距离，包括Hooks，表面上看推崇函数式组件，似乎是向函数式编程迈进了一步，但是，所有的Hooks函数都是有状态的，怎么能算纯函数呢。

当然，有洁癖一样追求纯函数也没有必要，既然“幂等”能够解决问题，我们也乐见其成。

印证了那句老话：只要你降低标准，会发现世界豁然开朗:)

P.S. 这篇文章里的背景知识如果不清楚，就去看我之前的Live吧，该说的知识点我都说过了。

《快速了解React的新功能Suspense和Hooks》

《深入理解React v16新功能》

《帮助你深入理解 React》