当初在理解 React CSR 时做过一个比喻，把单向数据流比作瀑布模型：
瀑布模型：由
props（水管）和state（水源）把组件组织起来，组件间数据流向类似于瀑布。数据流向总是从祖先到子孙（从根到叶子），不会逆流
（摘自深入 React）
单组件的微观视角下，我们把props理解为水管（数据通道），接收外部传递进来的数据（水），每一份state都是一处水源（想象泉眼冒水，即产生数据的地方），将这棵通过props管道连接而成的组件树立起来，就形成了自上而下的水流（瀑布）：
想象上图整面瀑布墙上有无数的泉眼，state值顺着props管道流淌
从更宏大的视角来看，组件树就像是一系列竹管连接起来的水车，数据是水源（state、props、context以及外部数据源），水自上而下地流经整个组件树到达叶子组件，渲染出漂亮的视图
先通过一张图来感受竹管输水：
再感受水源以及水车整体的运转：
左侧的小桶就是外部数据源，随时舀起一瓢灌到某个组件（竹管）中，让其内部的state（储水）发生变化，变化的水流经过整个子树到达叶子组件，渲染出变化后的视图，这就是交互操作导致数据变化时的组件更新过程
CSR 模式下，我们把水理解为数据，同样适用于 SSR，只是过程稍复杂些：
类比三体人的生存模式，乱纪元来临时先脱水成人干（SSR 中的服务端渲染部分），恒纪元到来后再泡水复活（SSR 中的客户端 hydrate 部分）
首先要有水可脱，所以先要拉取数据（水），在服务端完成组件首次渲染（mount）的过程：
也就是根据外部数据构建出初始组件树，过程中仅执行render及之前的几个生命周期，是为了尽可能缩短保命招数的前摇，尽快脱水
接着对组件树进行脱水，使其在恶劣的环境同样能够以一种更简单的形态“生存”下来，比如禁用了 JavaScript 的客户端环境
比组件树更简单的形态是 HTML 片段，脱去生命的水气（动态数据），成为风干标本一样的静态快照：
内存里的组件树被序列化成了静态的 HTML 片段，还能看出来人样（初始视图），不过已经无法与之交互了，但这种便携的形态尤其适合运输，能够通过网络传输到地球上的某个客户端
抵达客户端后，如果环境适宜（没有禁用 JavaScript），就立即开始“浸泡”（hydrate），组件随之复苏
客户端“浸泡”的过程实际上是重新创建了组件树，将新生的水（state、props、context等）注入其中，并将鲜活的组件树塞进服务端渲染的干瘪躯壳里，使之复活：
注水复活其实比三体人浸泡复苏更强大一些，能够修复肢体性的损伤（缺失的 HTML 结构会重新创建），但并不纠正口歪眼斜之类的小毛病（忽略属性多了少了、属性值对不上之类的问题，具体见React SSR 之原理篇）
P.S.浸泡也需要一定时间，所以在 SSR 模式下，客户端有一段时间是无法正常交互的，注水完成之后才能彻底复活（单向数据流和交互行为都恢复正常）
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。