我正在开发一个与fluxible一起使用的最小应用程序。几乎一切似乎都清楚，但只有一件事：脱水和再水合状态的概念。
我知道这是在客户端和服务器之间同步存储所需要的，但我不知道为什么。这条线对我来说很不清楚：
var exposed = 'window.App=' + serialize(app.dehydrate(context)) + ';';
在 server.js ( https://github.com/yahoo/fluxible/tree/master/examples/react-router )
如果你能用“更简单的词”告诉我这意味着什么，我将不胜感激。
上面的答案很好，但我认为我们仍然可以用比萨来更好地解释这个比喻。考虑回到未来 2 中的这个场景：
这个场景中有两个重要的组成部分：脱水的必胜客披萨和百得水合器。暂时忽略我们还需要一个脱水器来完成这个比喻。
脱水比萨饼是代表完整比萨饼所需的一切，但正如包装纸告诉我们的那样，“除非完全补充水分，否则不要食用”。服务器呈现的脱水比萨饼看起来很美味，但实际上并没有完全吸引人。
您的应用程序既是给 McFly 奶奶的保湿剂、比萨饼和比萨饼盒说明。奶奶 McFly 是浏览器。当用户请求“半意大利辣香肠/半青椒”比萨页面时，后端会发送一个脱水比萨和一个 Black & Decker 水合器。Grandma McFly（浏览器）仔细阅读所有说明并为用户补充比萨。这是一件非常好的事情，因为用户是个白痴，不知道也不关心含水比萨饼和脱水比萨饼之间的区别，就像 Marty Jr. 一样：
Marty Jr.: (os) 奶奶，你能把[脱水的披萨]塞进我嘴里吗？（笑）
马蒂：（os）你别傻了！
到目前为止一切顺利，对吧？到目前为止的好处：
但是等等，还有更多！用户抓起一两片然后跑掉，留下剩下的披萨。发生这种情况时，McFly 奶奶从比萨盒指令中知道要保存修改后的比萨状态。她（客户端）将其放入脱水器（未显示）并将其送回橱柜（服务器）。如果并且当用户回来完成他们的半意大利辣香肠/半胡椒比萨饼时，整个脱水比萨饼/水合器/奶奶过程将再次发生，它会像以往一样新鲜，加上他们所做的更改。
让我们来复习：
结束！除了不是真的。
让这个比喻起作用还有一个秘密的魔法部分，那就是每当我们给比萨加水时，我们实际上保持脱水比萨完好无损。所以我们最终得到了脱水比萨和水合比萨，然后我们在幕后根据需要同步它们。在 Flux 的情况下，这是通过许多商店组成您的应用程序来实现的。在 Redux 中，您只有一个顶级 Store，这可能更容易理解。
在 Fluxible 的上下文中，脱水意味着将其状态提取到对象中。再水化您的应用程序是使用相同的对象在您的应用程序中重新注入状态。表示应用程序状态的对象应该是可序列化的，以便通过网络发送。
假设我想在服务器上预渲染我的应用程序，将 html 提供给客户端，然后在客户端上重新渲染我的应用程序。如果我的应用程序仅包含静态数据，这将是微不足道的。但是，我的应用程序是有状态的：它在初始渲染之前从我的 API 检索数据并存储它。通过在服务器上提取我的应用程序的状态，将其与 HTML 一起发送，然后在客户端上重新注入，我避免向我的 API 发出两个请求。
脱水是序列化的另一个词，再水化意味着反序列化。
膨胀 == （重新）补水 == 反序列化
所以这行代码序列化了路由器的状态并将对象分配给window.app，它可以从客户端访问
更新
如何使用序列化的示例：
假设我们有一个用户对象，并希望在请求之间保留当前登录用户的引用。我们可以通过简单地获取用户的 id 并将其保存到会话中来序列化用户。那将是用户对象的序列化或脱水。为了水合或反序列化，我们只需从会话中获取 id，在 DB 中找到我们的用户并再次填写用户对象。此处的目的是使内存占用尽可能低。
在 Fluxible 的一个示例中，脱水函数只返回当前状态名称，水合物函数将状态名称作为参数并将其设置为当前状态。我认为完整的状态对象在客户端和服务器上都可用。因此，由于您不需要发送整个州，您只需发送州的名称。脱水的功能很简单
State.dehydrate = function(){
return this.currentStateName;
}