React Concurrent Mode 之 Suspense 实践

本文首发于我的个人博客: https://teobler.com ,转载请注明出处

自从三大框架成型之后，各个框架都为提升开发者的开发效率作出了不少努力，但是看起来技术革新都到了一个瓶颈。除了 React 引入了一次函数式的思想，感觉已经没有当初从DOM时代到数据驱动时代的惊艳感了。于是 React 将精力放在了用户体验上，想让开发者在不过多耗费精力的情况下，用框架自身去提升用户体验。

于是在最近的几个版本中，React 引入了一个叫做 Concurrent Mode 的东西，同时还引入了 Suspense，旨在提升用户的访问体验，React 应用在慢慢变大以后会慢慢变得越来越卡，这次的新功能就是想在应用初期就解决这些问题。

虽然现在这些功能还处在实验阶段，React 团队并不建议在生产环境中使用，不过大部分功能已经完成了，而且他们已经用在了新的网站功能中，所以面对这样一个相对成熟的技术，其实我们还是可以来自己玩一下的，接下来我来带领大家看看这是一个什么样的东西吧。

Concurrent Mode

WHAT

那么这个 Concurrent Mode 是个啥呢？

Concurrent Mode is a set of new features that help React apps stay responsive and gracefully adjust to the user’s device capabilities and network speed.

在官网的解释中， Concurrent Mode 包含了一系列新功能，这些新功能可以根据用户不同的设备性能和不同的网速进行不同的响应，以使得用户在不同的设备和网速的情况下拥有最好的访问体验。那么问题来了，它是怎么做到这一点的呢？

HOW

可停止的rendering (Interruptible Rendering)

在通常状况下，React 在 render 的时候是没有办法被打断的（这其中有创建新的 DOM 节点等等），rendering 的过程会一直占用 JS 线程，导致此时浏览器无法对用户的操作进行实时反馈，造成了一种整个页面很卡的感觉。

而在 Concurrent Mode 下，rendering 是可以被打断的，这意味着 React 可以让出主线程给浏览器用于更紧急的用户操作。

想象这样一个通用的场景：用户在一个输入框中检索一些信息，输入框中的文字改变后页面都将重新渲染以展示最新的结果，但是你会发现每一次输入都会卡顿，因为每一次重新渲染都将阻塞主线程，浏览器就将没有办法相应用户在输入框中的输入。当然现在通用的解决办法是用 debouncing 或者 throtting。但是这个方式存在一些问题，首先是页面没有办法实时反应用户的输入，用户会发现可能输入了好多个字符页面才刷新一次，不会实时更新；第二个问题是在性能比较差的设备上还是会出现卡顿的情况。

如果在页面正在 render 时用户输入了新的字符，React 可以暂停 render 让浏览器优先对用户的输入进行更新，然后 React 会在内存中渲染最新的页面，等到第一次 render 完成后再直接将最新的页面更新出来，保证用户能看到最新的页面。

这个过程有点像 git 的多分支，主分支是用户能够看到的并且是可以被暂停的，React 会新起一个分支来做最新的渲染，当主分支的渲染完成后就将新的分支合并过来，得到最新的视图。

可选的加载顺序(Intentional Loading Sequences)

在页面跳转的时候，为了提升用户体验，我们往往会在新的页面中加上 skeleton，这是为了防止要渲染的数据还没有拿到，用户看到一个空白的页面。

在 Concurrent Mode 中，我们可以让 React 在第一个页面多停留一会，此时 React 会在内存中用拿到的数据渲染新的页面，等页面渲染完成后再直接跳转到一个已经完成了的页面上，这个行为要更加符合用户直觉。而且需要说明的是，在第一个页面等待的时间里，用户的任何操作都是可以被捕捉到的，也就是说在等待时间内并不会 block 用户的任何操作。

总结

总结一下就是，新的 Concurrent Mode 可以让 React 同时在不同的状态下进行并行处理，在并行状态结束后又将所有改变合并起来。这个功能主要