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开始,一个组件的生命周期可以分为两个阶段: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 ( loading...
}> ); }; export default SuspenseDemo;

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

的确有点矛盾。

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

React Supense和React 异步渲染的一点矛盾_第1张图片

简单说来,就是降低了要求,只需要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 异步渲染的一点矛盾)