What does « dehydrate » and « rehydrate » stand for in Fluxible?

Question

I'm working on a minimal app which work with fluxible. Pretty much everything seems clear but one thing : the concept of dehydrate and rehydrated state.

I've understood that it's what's needed to sync the store between the client and the server, but I don't know why. This line is very unclear to me :

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

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

I would really appreciate if you could tell me in « simpler word » what it means.

Answer 1

The above answers are great, but I think we could still explain this metaphor a little better, with pizza. Consider this scene from Back to The Future 2:

There are two crucial components in this scene: the dehydrated Pizza Hut pizza and the Black & Decker hydrator. Ignore for a moment that we'll also need a dehydrator to complete the metaphor.

The dehydrated pizza is everything necessary for the representation of a complete pizza, but as the wrapper tells us, "DO NOT CONSUME UNLESS FULLY REHYDRATED". The dehydrated pizza as rendered by the server and looks tasty, but is actually not fully engaging by itself.

Your app is both hydrator, pizza, and pizza box instructions for Grandma McFly. Grandma McFly is the browser. When a user requests the "half pepperoni / half green peppers" pizza page, the backend sends a dehydrated pizza AND a Black & Decker hydrator. Grandma McFly (browser) carefully reads all of the instructions and hydrates the pizza for the user. This is a very good thing since the user is an idiot and doesn't know or care about the difference between the hydrated and dehydrated pizzas, just like Marty Jr. :

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!

So far so good, right? Benefit so far:

• the user gets the whole (dehydrated) pizza and the hydrator on the first request, rather than just getting the hydrator and having to make a (web service xhr) call to order the pizza
• web crawlers are especially dumb users, who get everything they need from looking at frozen pizzas and don't need a Grandma McFly to read the instructions and make the pizza interactive by hydrating it

But wait, there's more! The user grabs a slice or two and then runs off, leaving the rest of the pizza. As that happens, Grandma McFly knows from pizza box instructions to save the modified pizza state. She (client-side) puts it in a dehydrator (not shown) and sends it back into the cupboard (server). If and when the user comes back to finish their half pepperoni / half pepper pizza, the whole dehydrated pizza / hydrator / Grandma process will happen again and it will be fresh as ever, plus the changes they made.

Let's review:

• To dehydrate is to extract the current state of an app and serialize it into an object. This can be done server side or client side.
• To rehydrate is to interpret the state object (created through dehydration) and render the app into a tasty interactive pizza.
• It is useful to pass a dehydrated state object in either direction: from the server to the client, or the client to the server.

The end! Except not really.

There is still one secret magic part to get this metaphor to work, which is that whenever we hydrate a pizza we actually keep the dehydrated pizza intact. So we wind up with both a dehydrated pizza and a hydrated pizza, and then we synchronize them as necessary behind the scenes. In the case of Flux, this takes place through however many Stores make up your app. In Redux you just have a single top level Store, which can be a bit simpler to understand.