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

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.

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.

In the context of Fluxible, dehydrating your application means extracting its state into an object. Rehydrating your app is using that same object to reinject state in your application. The object representing the state of your application should be serializable in order to send it over the network.

Say I want to pre-render my app on the server, serve the html to the client, then re-render my app on the client. This would be trivial if my app only consisted of static data. However, my app is stateful: it retrieves data from my API before the initial render and stores it. By extracting the state of my app on the server, sending it along with the HTML, then reinjecting it on the client, I avoid making two requests to my API.

Dehydrate is another word for serialize and Rehydrate means deserialize.

Inflating == (re)hydrating == deserialization

So the line of code serializes a state of router and assign the object to window.app which is accessible from client

Update

Example of how can serialisation be used:

Assume we have a user object and want to keep a reference of currently logged in user between requests. We can serialize the user by simply taking its id and save it into session. That would be serialisation or dehydration of user object. To hydrate or deserialize we simply take the id from session, find our user in DB and fill in the user object again. The purpose here is to keep memory footprint as low as possible.

In one of the examples of fluxible the dehydrate function simply returns current state name and the hydrate function takes the state name as an argument and set it as current state. I think that the full states objects are available on the client as well as the server. So since you don't need to send the entire state you only send state's name. The function to dehydrate is as simple as

State.dehydrate = function(){
    return this.currentStateName;
}