node.js - Fluxible 中的“脱水”和“再水合”代表什么？

Question

我正在开发一个与 Fluxible 配合使用的最小应用程序。几乎所有事情看起来都很清楚，但只有一件事:脱水和再水合状态的概念。

我知道这是在客户端和服务器之间同步存储所需要的，但我不知道为什么。这条线对我来说很不清楚:

 var exposed = 'window.App=' + serialize(app.dehydrate(context)) + ';';

在 server.js 中 (https://github.com/yahoo/fluxible/tree/master/examples/react-router)

如果你能用“更简单的词”告诉我这意味着什么，我将不胜感激。

Answer 1

上面的答案很好，但我认为我们仍然可以更好地解释这个比喻，用比萨饼。考虑一下《回到 future 2》中的这个场景:

这个场景中有两个关键组件:脱水的必胜客披萨和Black & Decker 保湿器。 暂时忽略我们还需要脱水机来完成比喻。

脱水的比萨饼是代表完整比萨饼所需的一切，但正如 wrapper 告诉我们的那样，“除非完全补充水分，否则不要食用”。服务端渲染的脱水披萨看起来很好吃，但实际上并没有完全吸引人。

您的应用既是给 McFly 奶奶使用的补水器、比萨饼和比萨盒说明。 Grandma McFly 是浏览器。当用户请求“半意大利辣香肠/半青椒”比萨页面时，后端会发送一个脱水比萨和一个 Black & Decker 水合器。 Grandma McFly(浏览器)仔细阅读所有说明并为用户补充比萨。这是一件非常好的事情，因为用户是个白痴，不知道也不关心含水比萨饼和脱水比萨饼之间的区别，就像小马蒂一样:

Marty Jr.: (o.s) Grandma, can you just shove [the dehydrated pizza] in my mouth? (laughs)

Marty: (o.s) Don't you be a smart ass!

到目前为止一切都很好，对吧？到目前为止的好处:

• 用户在第一次请求时就得到了整个(脱水的)比萨饼和水合器，而不是仅仅得到水合器并且必须进行(网络服务 xhr)调用来订购比萨饼
• 网络爬虫是特别愚蠢的用户，他们通过查看冷冻比萨饼来获得所需的一切，并且不需要 McFly 奶奶阅读说明并通过为比萨饼补水使比萨饼具有互动性

但是等等，还有更多!用户抓起一两片然后跑掉，留下剩下的披萨。发生这种情况时，McFly 奶奶从比萨盒指令中知道要保存修改后的比萨状态。她(客户端)将其放入脱水器(未显示)并将其送回橱柜(服务器)。如果并且当用户回来完成他们的半意大利辣香肠/半胡椒比萨饼时，整个脱水比萨饼/水合器/奶奶过程将再次发生，并且它将一如既往地新鲜，加上他们所做的更改。

让我们回顾一下:

• 脱水是提取应用程序的当前状态并将其序列化为对象。这可以在服务器端或客户端完成。
• 再水化是解释状态对象(通过脱水创建)并将应用呈现为美味的交互式披萨。
• 在任一方向传递脱水状态对象很有用:从服务器到客户端，或从客户端到服务器。

结束!除了不是真的。

要让这个比喻起作用，还有一个 secret 的魔法部分，那就是每当我们给披萨加水时，我们实际上保持脱水的披萨完好无损。所以我们最终得到了脱水比萨和水合比萨，然后我们在幕后根据需要同步它们。在 Flux 的情况下，这是通过许多商店组成您的应用程序来实现的。在 Redux 中，您只有一个顶级 Store，这可能更容易理解。