¿A dónde va la lógica en los sitios Jamstack?

Aquí hay algo que tenía que entender cuando comencé a crear sitios Jamstack. Existen diferentes etapas por las que pasa su sitio en las que puede poner lógica.

Veamos un ejemplo especial para que puedas ver a qué me refiero. Digamos que estás creando un sitio web para un local de música. La parte más importante del sitio es una lista de eventos, algunos del pasado y otros próximos. Desea asegurarse de etiquetarlos como cuentos o diseñarlos para que queden muy claros. Esa es la lógica basada en fechas. ¿Cómo haces eso? ¿Dónde vive esa lógica?

Hay al menos cuatro lugares a considerar cuando se trata de Jamstack.

Opción 1: escribirlo nosotros mismos en el HTML

Literalmente, siéntese y escriba un archivo HTML que represente todos los eventos. Miraríamos la fecha del evento, decidiríamos si es en el pasado o en el futuro y escribiríamos contenido diferente para cada caso. Confirme e implemente ese archivo.

h1Upcoming Event: Bill's Banjo Night/h1h1Past Event: 70s Classics with Jill/h1

¡Esto funcionaría totalmente! Pero la desventaja es que tendríamos que actualizar ese archivo HTML todo el tiempo: una vez que termine Bill's Banjo Night, tenemos que abrir el editor de código, cambiar “Próximo” a “Pasado” y volver a cargar el archivo.

Opción 2: escribir datos estructurados y aplicar lógica en el momento de la compilación

En lugar de escribir todo el HTML a mano, creamos un archivo Markdown para representar cada evento. La información importante, como la fecha y el título, se encuentra allí como datos estructurados. Esa es sólo una opción. El punto es que tenemos acceso a estos datos directamente. Podría ser un CMS sin cabeza o algo así también.

Luego configuramos un generador de sitios estáticos, como Eleventy, que lee todos los archivos Markdown (o extrae la información de su CMS) y los convierte en archivos HTML. Lo bueno es que podemos ejecutar cualquier lógica que queramos durante el proceso de construcción. Haga cálculos deseados, acceda a las API, ejecute un corrector ortográfico… el cielo es el límite.

Para nuestro sitio de sala de música, podríamos representar eventos como archivos Markdown como este:

---title: Bill's Banjo Nightdate: 2020-09-02---The event description goes here!

Luego, ejecutamos un poco de lógica durante el proceso de construcción escribiendo una plantilla como esta:

{% if event.date  now %}  h1Upcoming Event: {{event.title}}/h1{% else %}  h1Past Event: {{event.title}}/h1{% endif %}

Ahora, cada vez que se ejecuta el proceso de compilación, mira la fecha del evento, decide si es en el pasado o en el futuro y produce HTML diferente basado en esa información. ¡No más cambios de HTML a mano!

El problema con este enfoque es que la comparación de fechas sólo ocurre una vez, durante el proceso de construcción. La nowvariable en el ejemplo anterior se referirá a la fecha y hora en que se ejecuta la compilación. Y una vez que hayamos cargado los archivos HTML que produjeron la compilación, no cambiarán hasta que ejecutemos la compilación nuevamente. Esto significa que una vez que finaliza un evento en nuestro lugar de música, tendríamos que volver a ejecutar la compilación para asegurarnos de que el sitio web lo refleja.

Ahora, podríamos automatizar la reconstrucción para que suceda una vez al día, o incluso una vez cada hora. Eso es literalmente lo que hace el sitio de conferencias CSS-Tricks a través de Zapier.

Pero esto podría acumular minutos de compilación si estás utilizando un servicio como Netlify, y aún podría haber casos extremos en los que alguien obtenga una versión desactualizada del sitio.

Opción 3: aplicar lógica en el borde

Los trabajadores perimetrales son una forma de ejecutar código a nivel de CDN cada vez que llega una solicitud. No están ampliamente disponibles al momento de escribir este artículo pero, una vez que lo estén, podríamos escribir nuestra comparación de fechas de esta manera:

// THIS DOES NOT WORKimport eventsList from "./eventsList.json"function onRequest(request) {  const now = new Date();  eventList.forEach(event = {    if (event.date  now) {      event.upcoming = true;    }  })  const props = {    events: events,  }  request.respondWith(200, render(props), {})}

La render()función tomaría nuestra lista procesada de eventos y la convertiría en HTML, tal vez inyectándola en una plantilla pre-renderizada. La gran promesa de los trabajadores de frontera es que son extremadamente rápidos, por lo que podríamos ejecutar esta lógica del lado del servidor y al mismo tiempo disfrutar de los beneficios de rendimiento de una CDN.

Y debido a que el trabajador perimetral se ejecuta cada vez que alguien solicita el sitio web, podemos estar seguros de que obtendrá una versión actualizada del mismo.

Opción 4: hacer lógica en tiempo de ejecución

Finalmente, podríamos pasar nuestros datos estructurados al front-end directamente, por ejemplo, en forma de atributos de datos. Luego escribimos JavaScript que hará cualquier lógica que necesitemos en el dispositivo del usuario y manipulará el DOM sobre la marcha.

Para nuestro sitio de sala de música, podríamos escribir una plantilla como esta:

h1 data-date="{{event.date}}"{{event.title}}/h1

Luego, hacemos nuestra comparación de fechas en JavaScript después de cargar la página:

function processEvents(){  const now = new Date()  events.forEach(event = {    const eventDate = new Date(event.getAttribute('data-date'))    if (eventDate  now){        event.classList.add('upcoming')    } else {        event.classList.add('past')    }  })}

La nowvariable refleja la hora en el dispositivo del usuario, por lo que podemos estar bastante seguros de que la lista de eventos estará actualizada. Debido a que estamos ejecutando este código en el dispositivo del usuario, incluso podríamos ser convenientes y hacer cosas como ajustar la forma en que se muestra la fecha según el idioma o la zona horaria del usuario.

Y a diferencia de los puntos anteriores del ciclo de vida, el tiempo de ejecución dura mientras el usuario tenga abierta nuestra web. Entonces, si quisiéramos, podríamos ejecutar processEvents()cada pocos segundos y nuestra lista se mantendría perfectamente actualizada sin tener que actualizar la página. Probablemente esto sería innecesario para el sitio web de nuestro local de música, pero si quisiéramos mostrar los eventos en un cartel fuera del edificio, podría resultar útil.

¿Dónde pondrás la lógica?

Aunque uno de los conceptos centrales de Jamstack es que hacemos todo el trabajo que podemos en el momento de la compilación y entregamos HTML estático, aún podemos decidir dónde colocar la lógica.

¿Dónde lo pondrán?

Realmente depende de lo que estés intentando hacer. Las partes de su sitio que casi nunca cambian se pueden completar en el momento de la edición. Cuando se encuentre cambiando una pieza de información una y otra vez, probablemente sea un buen momento para moverla a un CMS e incorporarla en el momento de la compilación. Las características que son urgentes (como los ejemplos de eventos que usamos aquí), o que dependen de información sobre el usuario, probablemente deban ocurrir más adelante en el ciclo de vida en el borde o incluso en el tiempo de ejecución.