React SSR中的hydrate是什么意思？

React CSR：水车模型

当初在理解 React CSR 时做过一个比喻， 把单向数据流比作瀑布模型 ：

瀑布模型：由 props （水管）和 state （水源）把组件组织起来，组件间数据流向类似于瀑布。数据流向总是从祖先到子孙（从根到叶子），不会逆流

（摘自深入 React）

单组件的微观视角下，我们把 props 理解为水管（数据通道），接收外部传递进来的数据（水），每一份 state 都是一处水源（想象泉眼冒水，即产生数据的地方），将这棵通过 props 管道连接而成的组件树立起来，就形成了自上而下的水流（瀑布）：

想象上图整面瀑布墙上有无数的泉眼， state 值顺着 props 管道流淌

从更宏大的视角来看， 组件树就像是一系列竹管连接起来的水车，数据是水源（ state 、 props 、 context 以及外部数据源），水自上而下地流经整个组件树到达叶子组件，渲染出漂亮的视图

先通过一张图来感受竹管输水：

再感受水源以及水车整体的运转：

左侧的小桶就是外部数据源， 随时舀起一瓢灌到某个组件（竹管）中，让其内部的 state （储水）发生变化，变化的水流经过整个子树到达叶子组件，渲染出变化后的视图，这就是交互操作导致数据变化时的组件更新过程

React SSR：三体人模型

CSR 模式下，我们把水理解为数据，同样适用于 SSR，只是过程稍复杂些：

1. 服务端渲染：在服务端注入数据，构建出组件树
2. 序列化成 HTML：脱水成人干
3. 客户端渲染：到达客户端后泡水，激活水流，变回活人

类比三体人的生存模式， 乱纪元来临时先脱水成人干（SSR 中的服务端渲染部分），恒纪元到来后再泡水复活（SSR 中的客户端 hydrate 部分）

喝水（render）

首先要有水可脱，所以先要拉取数据（水），在服务端完成组件首次渲染（mount）的过程：

也就是 根据外部数据构建出初始组件树 ，过程中仅执行 render 及之前的几个生命周期，是为了尽可能缩短保命招数的前摇，尽快脱水

脱水（dehydrate）

接着对组件树进行脱水，使其在恶劣的环境同样能够以一种更简单的形态“生存”下来，比如禁用了 JavaScript 的客户端环境

比组件树更简单的形态是 HTML 片段，脱去生命的水气（动态数据），成为风干标本一样的静态快照：

内存里的组件树被序列化成了静态的 HTML 片段， 还能看出来人样（初始视图），不过已经无法与之交互了 ，但这种便携的形态尤其适合运输，能够通过网络传输到地球上的某个客户端

注水（hydrate）

抵达客户端后，如果环境适宜（没有禁用 JavaScript），就立即开始“浸泡”（hydrate），组件随之复苏

客户端“浸泡”的过程实际上是重新创建了组件树，将新生的水（state、props、context等）注入其中，并将鲜活的组件树塞进服务端渲染的干瘪躯壳里，使之复活：

注水复活其实比三体人浸泡复苏更强大一些， 能够修复肢体性的损伤（缺失的 HTML 结构会重新创建），但并不纠正口歪眼斜之类的小毛病（忽略属性多了少了、属性值对不上之类的问题，具体见React SSR 之原理篇）

P.S.浸泡也需要一定时间，所以在 SSR 模式下，客户端有一段时间是无法正常交互的，注水完成之后才能彻底复活（单向数据流和交互行为都恢复正常）

参考资料

• 三体 I：地球往事

• 三体 II：黑暗森林