Что "обезвоживает" и "регидратирует" в Fluxible?

Я работаю над минимальным приложением, которое работает с флюсом. Практически все кажется ясным, но одно: концепция обезвоживания и регидратированного состояния.

Я понял, что это необходимо для синхронизации хранилища между клиентом и сервером, но я не знаю почему. Эта строка для меня очень неясна:

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

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

Я был бы очень признателен, если бы вы могли сказать мне в "более простом слове", что это значит.

Ответ 1

В контексте Fluxible обезвоживание вашего приложения означает извлечение его состояния в объект. Возобновление вашего приложения использует тот же объект для состояния reject в вашем приложении. Объект, представляющий состояние вашего приложения, должен быть сериализуемым, чтобы отправить его по сети.

Предположим, что я хочу предварительно отобразить свое приложение на сервере, передать html клиенту, а затем повторно отобразить приложение на клиенте. Это было бы тривиально, если бы мое приложение состояло только из статических данных. Тем не менее, мое приложение stateful: оно извлекает данные из моего API до первоначального рендеринга и сохраняет его. Извлекая состояние моего приложения на сервере, отправляя его вместе с HTML, а затем повторно добавляя его на клиент, я не делаю два запроса на свой API.

Ответ 2

Вышеупомянутые ответы велики, но я думаю, что мы все еще можем объяснить эту метафору немного лучше, с пиццей. Рассмотрим эту сцену из "Назад в будущее" 2:

В этой сцене есть два важных компонента: обезвоженная пицца Pizza Hut и гидратор Black & Decker. Игнорируйте на мгновение, что нам также понадобится дегидратор для завершения метафоры.

Обезвоженная пицца - это все, что необходимо для представления полной пиццы, но, как говорит обертка, "НЕ ПОТРЕБИТЕ, ЕСЛИ ПОЛНОСТЬЮ НЕ ПРОДОЛЖАЕТСЯ". Обезвоженная пицца, отображаемая сервером, выглядит вкусной, но на самом деле не полностью задействована сама по себе.

Ваше приложение представляет собой инструкцию гиганта, пиццы и пиццы для бабушки МакФлай. Бабушка МакФлай - браузер. Когда пользователь запрашивает страницу "pepperoni/half green peppers" на странице "pepperoni/half green peppers", бэкэнд отправляет обезвоженную пиццу и гидрант Black and Decker. Бабушка МакФлай (браузер) внимательно читает все инструкции и увлажняет пиццу для пользователя. Это очень хорошо, так как пользователь идиот и не знает или не заботится о различии между гидратированной и обезвоженной пиццей, как и Марти-младший:

Marty Jr.: (o.s) Бабушка, можете ли вы просто засунуть [обезвоженную пиццу] в рот? (Смеется)

Марти: (o.s) Разве ты не умная задница?

До сих пор так хорошо, правда? Выгода:

пользователь получает всю (обезвоженную) пиццу и гидратор по первому запросу, вместо того, чтобы просто получать гидратор и делать вызов (веб-сервис xhr) для заказа пиццы
веб-сканеры являются особенно тупыми пользователями, которые получают все, что им нужно, от взгляда на замороженные пиццы и не нуждаются в бабушке McFly, чтобы прочитать инструкции и сделать пиццу интерактивной, увлажнив ее.

Но подождите, там еще! Пользователь хватает ломтик или два, а затем убегает, оставив остальную часть пиццы. Как это происходит, бабушка МакФлай знает из инструкции пиццы, чтобы сохранить измененное состояние пиццы. Она (клиентская сторона) помещает ее в дегидратор (не показана) и отправляет обратно в шкаф (сервер). Если и когда пользователь вернется, чтобы закончить свою половину пепперони/половину перечной пиццы, весь дегидратированный процесс пиццы/гидратора/бабушки снова повторится, и он будет свежим, как всегда, плюс изменения, которые они сделали.

Давайте рассмотрим:

Чтобы обезводить - извлечь текущее состояние приложения и сериализовать его в объект. Это можно сделать на стороне сервера или на стороне клиента.
Для регидратации следует интерпретировать объект состояния (созданный путем обезвоживания) и превращать приложение в вкусную интерактивную пиццу.
Полезно передать обезвоженный объект состояния в любом направлении: от сервера к клиенту или клиента к серверу.

Конец! Кроме того, что нет.

Есть еще одна секретная магическая часть, чтобы заставить эту метафору работать, а это значит, что всякий раз, когда мы увлажняем пиццу, мы фактически сохраняем обезвоженную пиццу. Таким образом, мы заканчиваем обе обезвоженной пиццей и гидратированной пиццей, а затем мы синхронизируем их по необходимости за кулисами. В случае с Flux это происходит, несмотря на то, что многие магазины составляют ваше приложение. В Redux у вас есть только один магазин верхнего уровня, который может быть немного проще понять.

Ответ 3

Дегидрат - это еще одно слово для сериализации, а регидрат означает десериализацию.

Надувание == (re) увлажнение == десериализация

Итак, строка кода сериализует состояние маршрутизатора и назначает объект window.app, доступный из клиента

Обновление

Пример использования сериализации:

Предположим, что у нас есть объект пользователя, и мы хотим сохранить ссылку на пользователя, зарегистрированного в настоящее время между запросами. Мы можем сериализовать пользователя, просто используя его идентификатор и сохраняя его в сеансе. Это будет сериализация или обезвоживание объекта пользователя. Для гидратации или десериализации мы просто берем идентификатор из сеанса, находим нашего пользователя в БД и снова заполняем объект пользователя. Цель состоит в том, чтобы сохранить максимально возможную площадь памяти.

В одном из примеров флюксируемого функция дегидрата просто возвращает имя текущего состояния, а функция гидрата принимает имя состояния в качестве аргумента и устанавливает его как текущее состояние. Я думаю, что объекты полного состояния доступны как на клиенте, так и на сервере. Поэтому, поскольку вам не нужно отправлять все состояние, вы отправляете только имя штата. Функция обезвоживания так же проста, как

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