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