node.js - ¿Qué significa "deshidratar" y "rehidratar" en Fluxible?
reactjs (3)
Deshidratar es otra palabra para serializar y rehidratar significa deserializar.
Inflar == (re) hidratar == deserialización
Entonces la línea de código serializa un estado de enrutador y asigna el objeto a window.app que es accesible desde el cliente
Actualizar
Ejemplo de cómo se puede usar la serialización:
Supongamos que tenemos un objeto de usuario y queremos mantener una referencia del usuario actualmente conectado entre las solicitudes. Podemos serializar al usuario simplemente tomando su identificación y guardarla en sesión. Eso sería serialización o deshidratación del objeto del usuario. Para hidratar o deserializar, simplemente tomamos el ID de la sesión, buscamos a nuestro usuario en DB y completamos el objeto de usuario nuevamente. El objetivo aquí es mantener la huella de memoria lo más baja posible.
En uno de los ejemplos de fundente, la función de deshidratación simplemente devuelve el nombre de estado actual y la función de hidratación toma el nombre de estado como argumento y lo establece como estado actual. Creo que los objetos de estados completos están disponibles tanto en el cliente como en el servidor. Entonces, como no necesita enviar el estado completo, solo envía el nombre del estado. La función de deshidratar es tan simple como
State.dehydrate = function(){
return this.currentStateName;
}
Estoy trabajando en una aplicación mínima que funciona con fundente. Casi todo parece claro, pero una cosa: el concepto de deshidratar y estado rehidratado.
Entendí que es lo que se necesita para sincronizar la tienda entre el cliente y el servidor, pero no sé por qué. Esta línea no está muy clara para mí:
var exposed = ''window.App='' + serialize(app.dehydrate(context)) + '';'';
En server.js ( https://github.com/yahoo/fluxible/tree/master/examples/react-router )
Realmente apreciaría si pudieras decirme en una palabra más simple qué significa.
En el contexto de Fluxible, deshidratar su aplicación significa extraer su estado en un objeto. Rehidratar tu aplicación está usando ese mismo objeto para reinyectar el estado en tu aplicación. El objeto que representa el estado de su aplicación debe ser serializable para enviarlo a través de la red.
Supongamos que quiero preprocesar mi aplicación en el servidor, servir el html para el cliente y luego volver a procesar mi aplicación en el cliente. Esto sería trivial si mi aplicación solo consistiera en datos estáticos. Sin embargo, mi aplicación es con estado : recupera datos de mi API antes de la renderización inicial y la almacena. Al extraer el estado de mi aplicación en el servidor, enviarla junto con el HTML y reinyectarla en el cliente, evito hacer dos solicitudes a mi API.
Las respuestas anteriores son geniales, pero creo que aún podríamos explicar esta metáfora un poco mejor, con pizza . Considera esta escena de Back to The Future 2:
Hay dos componentes cruciales en esta escena: la pizza Pizza Hut deshidratada y el hidratador Black & Decker . Ignore por un momento que también necesitaremos un deshidratador para completar la metáfora.
La pizza deshidratada es todo lo necesario para la representación de una pizza completa, pero como nos dice el envoltorio, "NO CONSUMA A MENOS QUE SEA REHIDRIDO COMPLETAMENTE". La pizza deshidratada tal como la representa el servidor y se ve deliciosa, pero en realidad no es completamente atractiva por sí misma.
Su aplicación es instrucciones de hidratador, pizza e caja de pizza para Grandma McFly. Grandma McFly es el navegador . Cuando un usuario solicita la página de pizza "half pepperoni / half green peppers", el servidor envía una pizza deshidratada Y un hidratador Black & Decker. Grandma McFly (navegador) lee cuidadosamente todas las instrucciones e hidrata la pizza para el usuario. Esto es algo muy bueno ya que el usuario es un idiota y no conoce ni se preocupa por la diferencia entre las pizzas hidratadas y deshidratadas, al igual que Marty Jr.:
Marty Jr .: (OS) Abuela, ¿puedes empujar [la pizza deshidratada] en mi boca? (risas)
Marty: (OS) ¡No seas un asno inteligente!
Hasta aquí todo bien, ¿no? Beneficio hasta el momento:
- el usuario obtiene la pizza entera (deshidratada) y el hidratador en la primera solicitud, en lugar de simplemente obtener el hidratador y tener que hacer una llamada (servicio web xhr) para pedir la pizza
- los rastreadores web son usuarios especialmente tontos, que obtienen todo lo que necesitan de mirar pizzas congeladas y no necesitan una abuela McFly para leer las instrucciones y hacer que la pizza sea interactiva al hidratarla
¡Pero espera hay mas! El usuario toma una o dos rebanadas y luego sale corriendo, dejando el resto de la pizza. Mientras eso sucede, la abuela McFly sabe por las instrucciones de la caja de pizza para guardar el estado modificado de la pizza. Ella (del lado del cliente) lo coloca en un deshidratador (no se muestra) y lo envía de vuelta al armario (servidor). Si el usuario regresa para terminar su pizza de medio pepperoni / half pepper, todo el proceso deshidratado de pizza / hidratador / abuela volverá a suceder y estará más fresco como siempre, más los cambios que hicieron.
Revisemos:
- Deshidratar es extraer el estado actual de una aplicación y serializarla en un objeto. Esto puede hacerse desde el lado del servidor o desde el lado del cliente.
- Para rehidratar es interpretar el objeto de estado (creado a través de la deshidratación) y convertir la aplicación en una sabrosa pizza interactiva.
- Es útil pasar un objeto de estado deshidratado en cualquier dirección: del servidor al cliente o del cliente al servidor.
¡El fin! Excepto no realmente
Todavía hay una parte mágica secreta para que funcione esta metáfora, que es que cada vez que hidratamos una pizza mantenemos intacta la pizza deshidratada . Así que terminamos con una pizza deshidratada y una pizza hidratada, y luego sincronizamos según sea necesario detrás de escena. En el caso de Flux, esto se lleva a cabo a través de muchas tiendas que conforman su aplicación. En Redux solo tienes una única tienda de nivel superior, que puede ser un poco más simple de entender.