Catégories
Astuces et Design

Où Logic va-t-il sur les sites Jamstack?

Voici quelque chose dont je devais me concentrer lorsque j'ai commencé à créer des sites Jamstack. Il y a ces différents étapes votre site passe par là où vous pouvez mettre la logique.

Regardons un exemple spécial pour que vous puissiez voir ce que je veux dire. Supposons que vous créez un site Web pour une salle de concert. La partie la plus importante du site est une liste d'événements, certains dans le passé et d'autres à venir. Vous voulez vous assurer de les étiqueter comme tels ou de concevoir cela pour être très clair. C'est une logique basée sur la date. Comment tu fais ça? Où vit cette logique?

Il y a au moins quatre points à considérer en ce qui concerne Jamstack.

Option 1: écrivez-le nous-mêmes dans le HTML

Asseyez-vous littéralement et écrivez un fichier HTML qui représente tous les événements. Nous examinons la date de l'événement, décidons s'il s'agit du passé ou du futur, et rédigeons un contenu différent pour les deux cas. Validez et déployez ce fichier.

Upcoming Event: Bill's Banjo Night

Past Event: 70s Classics with Jill

Cela fonctionnerait totalement! Mais l’inconvénient est que nous devrons mettre à jour ce fichier HTML en permanence – une fois la soirée Banjo de Bill terminée, nous devons ouvrir votre éditeur de code, changer «À venir» en «Passé» et réimporter le fichier.

Option 2: Écrire des données structurées et faire de la logique au moment de la construction

Au lieu d'écrire tout le HTML à la main, nous créons un fichier Markdown pour représenter chaque événement. Des informations importantes telles que la date et le titre y figurent sous forme de données structurées. Ce n’est qu’une option. Le fait est que nous avons accès à ces données directement. Cela pourrait être un CMS sans tête ou quelque chose comme ça aussi.

Ensuite, nous mettons en place un générateur de site statique, comme Eleventy, qui lit tous les fichiers Markdown (ou extrait les informations de votre CMS) et les construit dans des fichiers HTML. La chose intéressante est que nous pouvons courir toute logique que nous voulons pendant le processus de construction. Faites des calculs sophistiqués, appuyez sur les API, exécutez une vérification orthographique… le ciel est la limite.

Pour notre site de salle de concert, nous pouvons représenter des événements sous forme de fichiers Markdown comme celui-ci:

---
title: Bill's Banjo Night
date: 2020-09-02
---

The event description goes here!

Ensuite, nous exécutons un peu de logique pendant le processus de construction en écrivant un modèle comme celui-ci:

{% if event.date > now %}
  

Upcoming Event: {{event.title}}

{% else %}  

Past Event: {{event.title}}

{% endif %}

Désormais, chaque fois que le processus de création s'exécute, il regarde la date de l'événement, décide s'il s'agit du passé ou du futur et produit un code HTML différent basé sur ces informations. Plus besoin de changer de HTML à la main!

Le problème avec cette approche est que la comparaison de dates ne se produit qu'une seule fois, pendant le processus de génération. le now variable dans l'exemple ci-dessus va faire référence à la date et à l'heure d'exécution de la construction. Et une fois que nous avons téléversé les fichiers HTML générés par la compilation, ceux-ci ne changeront pas tant que nous n'exécutons pas à nouveau la compilation. Cela signifie qu'une fois qu'un événement dans notre salle de concert est terminé, nous devons relancer la version pour nous assurer que le site Web reflète cela.

Maintenant, nous pourrions automatiser la reconstruction pour qu'elle se produise une fois par jour, ou diable, même une fois par heure. C'est littéralement ce que fait le site de conférences CSS-Tricks via Zapier.

Le site des conférences est déployé quotidiennement à l'aide d'une automatisation Zapier qui déclenche un déploiement Netlify, garantissant que les informations sont à jour.

Mais cela pourrait accumuler des minutes de construction si vous utilisez un service comme Netlify, et il peut y avoir des cas extrêmes où quelqu'un obtient une version obsolète du site.

Option 3: faire de la logique au bord

Les nœuds de calcul Edge sont un moyen d'exécuter du code au niveau CDN chaque fois qu'une demande arrive. Ils ne sont pas largement disponibles au moment de la rédaction de cet article, mais une fois qu'ils le sont, nous pourrions écrire notre comparaison de dates comme suit:

// THIS DOES NOT WORK
import 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), {})
}

le render() function prendrait notre liste d'événements traités et la transformerait en HTML, peut-être en l'injectant dans un modèle pré-rendu. La grande promesse des travailleurs de périphérie est qu’ils sont extrêmement rapides, ce qui nous permet d’exécuter cette logique côté serveur tout en bénéficiant des avantages des performances d’un CDN.

Et comme le travailleur de périphérie s'exécute chaque fois que quelqu'un demande le site Web, nous pouvons être sûrs qu'il en recevra une version à jour.

Option 4: faire de la logique au moment de l'exécution

Enfin, nous pourrions transmettre nos données structurées directement au front-end, par exemple sous la forme d'attributs de données. Ensuite, nous écrivons du code JavaScript qui fera toute la logique dont nous avons besoin sur l'appareil de l'utilisateur et manipule le DOM à la volée.

Pour notre site de salles de musique, nous pourrions écrire un modèle comme celui-ci:

{{event.title}}

Ensuite, nous faisons notre comparaison de dates en JavaScript après le chargement de la page:

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')
    }
  })
}

le now La variable reflète l'heure sur l'appareil de l'utilisateur, nous pouvons donc être sûrs que la liste des événements sera à jour. Étant donné que nous exécutons ce code sur l'appareil de l'utilisateur, nous pourrions même avoir de la fantaisie et faire des choses comme ajuster la façon dont la date est affichée en fonction de la langue ou du fuseau horaire de l'utilisateur.

Et contrairement aux points précédents du cycle de vie, le temps d'exécution dure aussi longtemps que l'utilisateur a ouvert notre site Web. Donc, si nous le voulions, nous pourrions courir processEvents() toutes les quelques secondes et notre liste resterait parfaitement à jour sans avoir à actualiser la page. Cela ne serait probablement pas nécessaire pour le site Web de notre salle de concert, mais si nous voulions afficher les événements sur un panneau d'affichage à l'extérieur du bâtiment, cela pourrait s'avérer utile.

Où allez-vous mettre la logique?

Bien que l'un des concepts fondamentaux de Jamstack soit que nous travaillons autant que possible au moment de la construction et servons du HTML statique, nous devons toujours décider où placer la logique.

Où allez-vous le mettre?

Cela dépend vraiment de ce que vous essayez de faire. Les parties de votre site qui ne changent presque jamais peuvent être complétées au moment de l'édition. Lorsque vous vous surprenez à modifier une information encore et encore, c'est probablement le bon moment pour la transférer dans un CMS et l'intégrer au moment de la construction. Les fonctionnalités qui sont sensibles au temps (comme les exemples d'événements que nous avons utilisés ici), ou qui reposent sur des informations sur l'utilisateur, doivent probablement se produire plus loin dans le cycle de vie à la périphérie ou même au moment de l'exécution.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *