React|React Supense和React 异步渲染的一点矛盾 ReactSupense和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开始，一个组件的生命周期可以分为两个阶段：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 {result} world; }; const SuspenseDemo = () => { return (); }; 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|React Supense和React 异步渲染的一点矛盾】《帮助你深入理解 React》