Un concepto clave de las aplicaciones Qwik es que son reanudables desde un estado renderizado del lado del servidor. La mejor manera de explicar la reanudabilidad es entender cómo la actual generación de frameworks es reproducible (hidratación).
Cuando una aplicación SSR/SSG arranca en un cliente, requiere que el framework en el cliente restaure tres piezas de información:
- Escuchadores: Localizar escuchadores de eventos e instalarlos en los nodos DOM para que la aplicación sea interactiva.
- Árbol de componentes: Construir una estructura de datos interna que represente el árbol de componentes de la aplicación.
- Estado de la aplicación: Restaurar el estado de la aplicación.
Colectivamente, esto se conoce como hidratación.
Todas las generaciones actuales de frameworks requieren este paso para que la aplicación sea interactiva.
La hidratación es costosa por dos razones:
- Los frameworks tienen que descargar todo el código de los componentes asociados a la página actual.
- Los frameworks tienen que ejecutar las plantillas asociadas a los componentes de la página para reconstruir la ubicación del listener y el árbol interno de componentes.
Qwik es diferente porque no requiere hidratación para reanudar una aplicación en el cliente. No requerir hidratación es lo que hace que el arranque de la aplicación Qwik sea instantáneo.
La hidratación de todos los demás frameworks replica toda la lógica de la aplicación en el cliente. Qwik en cambio pausa la ejecución en el servidor, y reanuda la ejecución en el cliente.
Introduciendo Resumability
La reanudación consiste en pausar la ejecución en el servidor y reanudarla en el cliente sin tener que reproducir y descargar toda la lógica de la aplicación.
Un buen modelo mental es que las aplicaciones Qwik en cualquier punto de su ciclo de vida pueden ser serializadas y movidas a una instancia VM diferente (servidor a navegador). Allí, la aplicación simplemente se reanuda donde se detuvo la serialización.
No se requiere hidratación. Por eso decimos que las aplicaciones Qwik no se hidratan; se reanudan.
Para lograr esto, Qwik necesita resolver los 3 problemas (listeners, árbol de componentes, estado de la aplicación) de una manera que sea compatible con un arranque sin código.
Si tu quieres aprender de Qwik a detalle, recuerda que tenemos WORKSHOP 🎉
Escuchadores
El DOM sin escuchadores de eventos es sólo una página estática; no es una aplicación. El estándar actual para todos los sitios es un nivel bastante alto de interactividad, por lo que incluso los sitios de aspecto más estático están llenos de escuchadores de eventos. Estos incluyen menús, hovers, detalles en expansión, o incluso aplicaciones interactivas completas.
Los frameworks existentes resuelven el problema de los escuchadores de eventos descargando los componentes y ejecutando sus plantillas para recoger los escuchadores de eventos que luego se adjuntan al DOM. El enfoque actual tiene estos problemas.
- Requiere que el código de la plantilla sea descargado ansiosamente.
- Requiere que el código de la plantilla se ejecute ansiosamente.
- Requiere que el código del manejador de eventos sea descargado ansiosamente (para ser adjuntado).
- Este enfoque no es escalable.
A medida que la aplicación se vuelve más complicada, la cantidad de código necesario para descargar ansiosamente y ejecutar crece proporcionalmente con el tamaño de la aplicación. Esto afecta negativamente al rendimiento del inicio de la aplicación y, por tanto, a la experiencia del usuario.
Qwik resuelve el problema anterior mediante la serialización de los oyentes de eventos en DOM así:
<button on:click="./chunk.js#handler_symbol">click me</button>Qwik todavía necesita recoger la información del oyente, pero este paso se realiza como parte del SSR/SSG. Los resultados de SSR/SSG se serializan en HTML para que el navegador no tenga que hacer nada para reanudar la ejecución.
Observa que el atributo on:click contiene toda la información para reanudar la aplicación sin hacer nada eagerly.
Qwikloader
Configura un único oyente global en lugar de muchos oyentes individuales por elemento DOM. Este paso se puede hacer sin código de aplicación presente.
El HTML contiene una URL al chunk y el nombre del símbolo.
El atributo le dice a Qwikloader qué trozo de código descargar y qué símbolo recuperar del trozo.
Finalmente, para hacer posible todo lo anterior, la implementación del procesamiento de eventos de Qwik entiende la asincronía que permite la inserción de lazy loading asíncrona.
Árboles de componentes
Los frameworks trabajan con árboles de componentes. Para ello, los frameworks necesitan una comprensión completa de los árboles de componentes para saber qué componentes necesitan ser rerenderizados y cuándo.
Si nos fijamos en la salida SSR/SSG de los frameworks existentes, la información sobre los límites de los componentes ha sido destruida.
No hay forma de saber dónde están los límites de los componentes mirando el HTML resultante. Para recrear esta información, los frameworks vuelven a ejecutar las plantillas de componentes y memorizan la ubicación de los límites de los componentes. La reejecución es la hidratación. La hidratación es costosa, ya que requiere tanto la descarga de plantillas de componentes como su ejecución.
Qwik recopila información sobre los límites de los componentes como parte del SSR/SSG y luego serializa esa información en HTML. El resultado es que Qwik puede:
- Reconstruir la información de jerarquía del componente sin que el código del componente esté realmente presente. El código del componente puede permanecer perezoso.
- Puede hacer esto perezosamente sólo para los componentes que necesitan ser re-renderizado en lugar de todos por adelantado.
- Recopila información sobre las relaciones entre las tiendas y los componentes.
- Esto crea un modelo de suscripción que informa a Qwik qué componentes necesitan ser re-renderizados como resultado de un cambio de estado. La información de suscripción también se serializa en HTML.
Estado de la aplicación
Los frameworks existentes suelen tener una forma de serializar el estado de la aplicación en HTML para que el estado pueda ser restaurado como parte de la hidratación. En este sentido, son muy similares a Qwik. Sin embargo, Qwik tiene la gestión del estado más estrechamente integrada en el ciclo de vida de los componentes.
En la práctica, esto significa que los componentes pueden cargarse en diferido independientemente de su estado. Esto no es fácil de conseguir en los frameworks existentes porque los props de los componentes suelen ser creados por el componente padre. Esto crea una reacción en cadena.
Para restaurar el componente X, sus padres necesitan ser restaurados también. Qwik permite reanudar cualquier componente sin que el código del componente padre esté presente.
Serialización
La forma más sencilla de pensar en la serialización es a través de JSON.stringify. Sin embargo, JSON tiene varias limitaciones. Qwik puede superar algunas limitaciones, pero algunas no pueden ser superadas, y ponen limitaciones en lo que el desarrollador puede hacer. Entender estas limitaciones es importante a la hora de construir aplicaciones Qwik.
Limitaciones de JSON que Qwik soluciona:
JSON produce un DAG.
DAG significa Directed Acyclic Graph, lo que significa que el objeto que está siendo serializado no puede tener referencias circulares. Esta es una gran limitación porque el estado de la aplicación es a menudo circular. Qwik asegura que cuando el gráfico de objetos se serializa, las referencias circulares se guardan correctamente y luego se restauran.
JSON no puede serializar algunos tipos de objetos. Por ejemplo, referencias DOM, o fechas. El formato de serialización de Qwik asegura que tales objetos puedan ser serializados y restaurados correctamente. Aquí hay una lista de tipos que pueden ser serializados con Qwik:
- Referencias DOM
- Promesas.
Cierres de función (si están envueltos en QRL) - Fechas Objetos URL
- Instancias de
MapySet. - Limitaciones de JSON que Qwik no resuelve:
- Serialización de clases (instanceof y prototype)
- Aunque algunas clases incorporadas, como
Date,URL,Map,Setestán soportadas. - Serialización de Streams
Escribir aplicaciones pensando en la serializabilidad
La capacidad de reanudación del marco de trabajo debe extenderse también a la reanudación de la aplicación. Esto significa que el framework debe proporcionar mecanismos para que el desarrollador exprese los componentes y entidades de la aplicación de forma que puedan serializarse y luego reanudarse (sin reiniciar).
Para ello es necesario que la aplicación se escriba teniendo en cuenta las limitaciones de la reanudabilidad. Simplemente no es posible que los desarrolladores continúen escribiendo aplicaciones centradas en el montón y esperen que un marco de trabajo mejor pueda compensar de alguna manera este enfoque subóptimo.
Los desarrolladores deben escribir sus aplicaciones centradas en el DOM. Esto requerirá un cambio de comportamiento y de las habilidades de los desarrolladores web. Los frameworks deben proporcionar orientación y APIs para facilitar a los desarrolladores la escritura de las aplicaciones de esta manera.
Otras ventajas de la resumibilidad
La ventaja más obvia de la reutilización es el renderizado del lado del servidor. Sin embargo, existen beneficios secundarios:
Serialización de aplicaciones PWA existentes para que los usuarios no pierdan el contexto cuando vuelvan a la aplicación. mejorar el rendimiento de la renderización, ya que sólo es necesario volver a renderizar los componentes modificados.
Carga perezosa detallada ya que se tiene menor presión de memoria, especialmente en dispositivos móviles, de igual manera la interactividad progresiva de sitios web estáticos existentes.
Es importante tener presente que una de las principales ventajas y uno de los grandes aportes de Qwik es la resumability, si tu deseas aprende más acerca de este concepto recuerda visitar el curso
