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开始，一个组件的生命周期能够分为两个阶段：render阶段+commit阶段。在render阶段的生命周期函数，因为Fiber的设计特点，可能会被打断，被打断之后，会从新被调用；而commit阶段一旦开始，就绝不会被打断。render阶段和commit阶段的分界线是render函数，留神，render函数自身属于render阶段。

举个例子，一个组件被渲染，执行到render函数外面，这时候用户忽然在某个input控件里输出了什么，这时候React决定去优先解决input控件里的按键事件，就会打断这个组件的渲染过程，也就是不论render返回啥，渲染过程都就此打住，不画了，分心去解决input控件的事件去了。等到那边的事件解决完，再来渲染这个组件，然而这时候从原来地位从新开始，那必定是不靠谱的，因为方才的按键事件处理可能扭转了一些状态，为了保障相对靠谱，React决定……还是从头走一遍吧， 于是，从新去调getDerivedStateFromProps、shouldComponentUpdate而后调用render。

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

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

什么叫纯函数？就是除了依据输出参数返回后果之外，不做任何多与事件的操作。

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

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

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

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

那么，当初问题来了，应用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函数（或者像下面例子一样在函数类型组件中）应用，那么获取数据的过程必定是在render阶段，然而，获取数据的过程是要调用AJAX的啊，AJAX是副作用操作，这不就和“render阶段不能做有副作用操作“的规定矛盾了吗？

确实有点矛盾。

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

简略说来，就是升高了要求，只须要render阶段的操作是”幂等“（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()如果有返回后果，那么返回的后果都是一样 ，也就达到了”幂等“的成果。

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

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

尽管一说React往往都说要说“函数式编程”，然而React真的先天和崇尚纯函数的“函数式编程”有很大间隔，包含Hooks，外表上看推崇函数式组件，仿佛是向函数式编程迈进了一步，然而，所有的Hooks函数都是有状态的，怎么能算纯函数呢。

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

印证了那句老话：只有你降低标准，会发现世界恍然大悟:)

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

《疾速理解React的新性能Suspense和Hooks》

《深刻了解React v16新性能》

《帮忙你深刻了解 React》