React CSR：水车模型
当初在了解 React CSR 时做过一个比喻，把单向数据流比作瀑布模型：
瀑布模型：由
props（水管）和state（水源）把组件组织起来，组件间数据流向相似于瀑布。数据流向总是从先人到子孙（从根到叶子），不会顺流
（摘自深刻 React）
单组件的宏观视角下，咱们把 props 了解为水管（数据通道），接管内部传递进来的数据（水），每一份 state 都是一处水源（设想泉眼冒水，即产生数据的中央），将这棵通过 props 管道连贯而成的组件建立起来，就造成了自上而下的水流（瀑布）：
设想上图整面瀑布墙上有有数的泉眼，state值顺着 props 管道流淌
从更巨大的视角来看，组件树就像是一系列竹管连接起来的水车，数据是水源（state、props、context以及内部数据源），水自上而下地流经整个组件树达到叶子组件，渲染出丑陋的视图
先通过一张图来感触竹管输水：
再感触水源以及水车整体的运行：
左侧的小桶就是内部数据源，随时舀起一瓢灌到某个组件（竹管）中，让其外部的state（储水）发生变化，变动的水流通过整个子树达到叶子组件，渲染出变动后的视图，这就是交互操作导致数据变动时的组件更新过程
React SSR：三体人模型
CSR 模式下，咱们把水了解为数据，同样实用于 SSR，只是过程稍简单些：
- 服务端渲染：在服务端注入数据，构建出组件树
- 序列化成 HTML：脱水成人干
- 客户端渲染：达到客户端后泡水，激活水流，变回活人
类比三体人的生存模式，乱纪元来长期先脱水成人干（SSR 中的服务端渲染局部），恒纪元到来后再泡水复活（SSR 中的客户端 hydrate 局部）
喝水（render）
首先要有水可脱，所以先要拉取数据（水），在服务端实现组件首次渲染（mount）的过程：
也就是 依据内部数据构建出初始组件树 ，过程中仅执行render 及之前的几个生命周期，是为了尽可能缩短保命招数的前摇，尽快脱水
脱水（dehydrate）
接着对组件树进行脱水，使其在顽劣的环境同样可能以一种更简略的状态“生存”下来，比方禁用了 JavaScript 的客户端环境
比组件树更简略的状态是 HTML 片段，脱去生命的水气（动态数据），成为风干标本一样的动态快照：
内存里的组件树被序列化成了动态的 HTML 片段，还能看进去人样（初始视图），不过曾经无奈与之交互了，但这种便携的状态尤其适宜运输，可能通过网络传输到地球上的某个客户端
注水（hydrate）
到达客户端后，如果环境合适（没有禁用 JavaScript），就立刻开始“浸泡”（hydrate），组件随之复苏
客户端“浸泡”的过程实际上是从新创立了组件树，将新生的水（state、props、context等）注入其中，并将鲜活的组件树塞进服务端渲染的干瘪躯壳里，使之复活：
注水复活其实比三体人浸泡复苏更弱小一些，可能修复肢体性的伤害（缺失的 HTML 构造会从新创立），但并不纠正口歪眼斜之类的小毛病（疏忽属性多了少了、属性值对不上之类的问题，具体见 React SSR 之原理篇）
P.S. 浸泡也须要肯定工夫，所以在 SSR 模式下，客户端有一段时间是无奈失常交互的，注水实现之后能力彻底复活（单向数据流和交互行为都恢复正常）
参考资料
- 三体 I：地球往事
- 三体 II：光明森林
有所得、有所惑，真好
关注「前端向后」微信公众号，你将播种一系列「用 心原创」的高质量技术文章，主题包含但不限于前端、Node.js 以及服务端技术
本文首发于 ayqy.net，原文链接：http://www.ayqy.net/blog/ssr-…