Navegando por las Islas de Interactividad

Entonces, ¿qué es una isla? Componente interactivo de JavaScript que se hidrata por separado del resto de tu página. Envías HTML estático desde tu servidor al cliente y luego cargas progresivamente el JavaScript que necesitas para los elementos interactivos de tu página. Se ve algo así.

Así que tienes tu página estática aquí. Tu encabezado puede tener componentes interactivos, tal vez una barra de búsqueda, tal vez un widget de compras. Tu carrusel de imágenes tendrá componentes interactivos de JavaScript, pero el resto de la página es solo HTML completamente estático y no necesita cargarse.

Entonces, ¿de dónde viene la arquitectura de islas? Bueno, la arquitectura de islas fue originalmente acuñada por Jason Miller, el creador de Preact, en 2021. Sin embargo, el concepto se remonta más atrás y él ha acreditado a KT Sillnull-Miller con acuñar islas de componentes, que es esta idea similar donde renderizas HTML en el servidor, luego hidratas esos componentes interactivos en la página en lugar de hidratar toda la página con JavaScript. Las islas han sido adoptadas por algunos diferentes frameworks, Astro, versiones anteriores de Marko, Fresh y Quig. También ha habido demostraciones en Eleventy y en Preact.

Entonces, ¿cómo usas las islas? Bueno, te voy a mostrar cómo usarlas específicamente en Astro y Fresh, dos frameworks que han integrado islas muy fuertemente. Pero hay ejemplos fantásticos por ahí sobre cómo implementarlas individualmente en tu propio framework. En Fresh, es muy simple. Todo lo que necesitas hacer es colocar tu componente en una carpeta de islas e importar esa isla donde necesites usarla. En Astro, es un poco más complicado. Puedes usar directivas del cliente en esos componentes del framework para cargarlos de diferentes maneras. Así que en este ejemplo, estamos importando el modelo de pago, que es un componente de React en nuestro archivo de Astro. Lo estamos usando aquí abajo y añadimos el componente client load. El componente client load renderizará el HTML en el servidor, lo enviará al cliente y luego hidratará el componente en la página. Esta es normalmente la forma en que funcionan las islas. Hay algunos otros. Así que en Astro, tenemos varias directivas del cliente diferentes. Client load es la habitual que usarás donde renderizas el elemento inmediatamente al cargar la página. Client idle esperará hasta que la página se haya cargado. Y luego, cuando la página esté inactiva, cargará tu componente. Client visible hidratará la página cuando entre en el viewport. Un formulario para el componente, que tiene un elemento interactivo, cualquier visitante que no se desplace hacia abajo hasta ese componente no recibirá ese JavaScript. Client media, así que si tienes un elemento que tal vez solo es visible en móvil, tal vez un cierto tipo de navegación, entonces puedes evitar cargarlo en pantallas más grandes. Client only es un poco especial. Solo se hidrata en el cliente.

Así que en lugar de pre-renderizar el HTML en el servidor, solo enviará el JavaScript al cliente. Esto puede causar algunos problemas con el cambio de diseño y cosas por el estilo. Pero también puede ser muy útil si no quieres renderizar ninguno de esos componentes en la página. Y puedes crear tus propias directivas. Un gran ejemplo fue rainy in New York, donde tu componente cliente solo se cargaría si estaba lloviendo en Nueva York. Pero puedes definir un pequeño componente, que te permitirá definir el comportamiento que desees. Eso podría ser si estás esperando que se presione un botón o si estás llamando a alguna API para averiguar si algún evento está ocurriendo.

Entonces, ¿cuáles son los beneficios de las islas? Bueno, páginas más pequeñas. No necesitas enviar el JavaScript donde no lo necesitas, y no necesitas enviar tanto de él. Y con eso, obtienes un LCP más rápido. No estás esperando que todo tu componente, toda tu página cargue JavaScript y ejecute ese JavaScript para toda la página. JavaScript es la forma más pesada de contenido que puedes enviar a una página. Así que cuanto menos, mejor. También carga componentes en paralelo. Si tienes tres, cuatro islas diferentes en una página, estas se cargarán en paralelo. No tienes que esperar a que una termine antes de cargar la siguiente. Y finalmente te da un control detallado sobre el JavaScript que envías a tus usuarios.

Entonces, ¿cuándo deberías usar islas? Bueno, hay algunos lugares diferentes. En eCommerce, puedes usarlas para modelos de productos, tarjetas, widgets de recomendación, cualquier tipo de elemento interactivo en la página. Pero dado que la mayor parte de tu página va a ser estática, no tiene ningún tipo de API, no va a ser una buena idea usar islas. Pero dado que la mayor parte de tu página va a ser estática, no tiene ningún tipo de interactividad, te permite reducir ese nivel de JavaScript que estás enviando a la nube. Sitios de medios, puedes usarlas para cargar reproductores de video, comentarios, modales, formularios, cualquier cosa que puedas necesitar. Documentos y blogs, áreas de juego de código, gráficos interactivos, cualquier tipo de pequeños componentes que requieran algo de JavaScript pero no signifiquen que quieras renderizar toda la página en JavaScript. Incluso si lo haces, puedes usarlas en paneles para pequeñas cantidades de hidratación con gráficos y filtros, o incluso para cargar toda tu aplicación. Pero, ¿cómo compartimos un estado entre todas estas diferentes islas? Las islas, especialmente en Astro, pueden ser de diferentes frameworks y no tienen una forma incorporada de compartir estado. Una de mis formas favoritas de hacer eso es usando una biblioteca llamada Nanostores. Nanostores es un gestor de estado muy pequeño que te permite compartir estado a través de prácticamente cualquier cosa. No tiene dependencias y tiene integraciones para Preact, React, Vue, Svelte, Angular. Puedes usarlo en una etiqueta de script normal.

Ejemplo rápido de Nanostores, importamos nuestro atom aquí. Creamos un pequeño, pequeño atom que contiene un número, y este es solo el número de artículos en un carrito. Puedes crear objetos más complejos, pero manteniéndolo simple aquí por ahora, tenemos dos elementos separados aquí. Estos son solo componentes básicos de React. Todo lo que necesitamos hacer es importar específicamente desde Nanostores react cuando queremos usar ese store, y luego podemos añadir y podemos modificar ese store obteniendo un estado de configuración como lo harías con cualquier tipo de store en otros lenguajes, solid y tal, pero este se puede importar en cualquier parte de tu aplicación.

Entonces, ¿cuáles son los puntos clave de las islas? Bueno, la web no tiene que ser una SPA. No tienes que enviar JavaScript para cada página, incluso si piensas que es uno de esos escenarios más complejos. Piensa primero en lo estático. Piensa en lo simple. Añade esa complejidad, añade esa interactividad, añade ese JavaScript según lo necesites. Mantén las cosas lo más simples posible, y añade a medida que avanzas. Usa directivas de cliente para más control. Si estás usando ASTRO o cualquier otro lenguaje que te dé más control sobre cómo cargas tu JavaScript, asegúrate de entender cuándo lo estás usando, cuándo lo estás cargando y cómo lo estás cargando. Si incluso necesitas cargarlo en primer lugar.

Puedes compartir estado entre islas muy fácilmente con stores. Nano stores es un ejemplo de eso, pero puedes escribir tu propio store con unas pocas líneas de JavaScript. Y eso es todo. Gracias por escuchar. Por favor, prueba ASTRO. Prueba fresh. Prueba islas. Déjame saber qué piensas. Muchas gracias.