Wo kommt Logik auf Jamstack-Websites vor?

Hier ist etwas, das ich verstehen musste, als ich anfing, Jamstack-Sites zu bauen. Es gibt diese verschiedenen Phasen, die Ihre Website durchläuft, in denen Sie Logik einbauen können.

Betrachten wir ein spezielles Beispiel, damit Sie sehen, was ich meine. Sagen wir, Sie erstellen eine Website für eine Musikveranstaltungsstätte. Der wichtigste Teil der Website ist eine Liste von Veranstaltungen, einige in der Vergangenheit und einige zukünftig. Sie möchten sicherstellen, dass diese als solche gekennzeichnet sind oder dass dies sehr deutlich ist. Das ist datumsbasierte Logik. Wie machen Sie das? Wo lebt diese Logik?

Es gibt mindestens vier Orte, die Sie bei Jamstack berücksichtigen können.

Option 1: Wir schreiben es selbst in HTML

Wir setzen uns buchstäblich hin und schreiben eine HTML-Datei, die alle Veranstaltungen repräsentiert. Wir würden das Datum der Veranstaltung betrachten, entscheiden, ob es Vergangenheit oder Zukunft ist, und für jeden Fall unterschiedliche Inhalte schreiben. Diese Datei committen und bereitstellen.

<h1>Upcoming Event: Bill's Banjo Night</h1>
<h1>Past Event: 70s Classics with Jill</h1>

Das würde total funktionieren! Aber der Nachteil ist, dass wir diese HTML-Datei ständig aktualisieren müssten – sobald Bill's Banjo Night vorbei ist, müssen wir unseren Code-Editor öffnen, "Upcoming" in "Past" ändern und die Datei neu hochladen.

Option 2: Strukturierte Daten schreiben und Logik zur Build-Zeit durchführen

Anstatt das gesamte HTML von Hand zu schreiben, erstellen wir eine Markdown-Datei, die jede Veranstaltung repräsentiert. Wichtige Informationen wie Datum und Titel sind dort als strukturierte Daten enthalten. Das ist nur eine Möglichkeit. Der Punkt ist, dass wir direkten Zugriff auf diese Daten haben. Es könnte auch ein Headless-CMS oder etwas Ähnliches sein.

Dann richten wir einen Static Site Generator ein, wie z. B. Eleventy, der alle Markdown-Dateien liest (oder die Informationen aus Ihrem CMS zieht) und sie zu HTML-Dateien kompiliert. Das Coole ist, dass wir beliebige Logik während des Build-Prozesses ausführen können. Komplexe Berechnungen durchführen, APIs aufrufen, Rechtschreibprüfungen durchführen ... der Himmel ist die Grenze.

Für unsere Musikveranstaltungs-Website könnten wir Veranstaltungen als Markdown-Dateien wie folgt darstellen

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

The event description goes here!

Dann führen wir während des Build-Prozesses ein wenig Logik aus, indem wir eine Vorlage wie diese schreiben

{% if event.date > now %}
  <h1>Upcoming Event: {{event.title}}</h1>
{% else %}
  <h1>Past Event: {{event.title}}</h1>
{% endif %}

Jetzt, jedes Mal, wenn der Build-Prozess ausgeführt wird, betrachtet er das Datum der Veranstaltung, entscheidet, ob es Vergangenheit oder Zukunft ist, und generiert basierend auf diesen Informationen unterschiedliche HTML-Dateien. Kein manuelles Ändern von HTML mehr!

Das Problem bei diesem Ansatz ist, dass der Datumsvergleich nur einmal stattfindet, während des Build-Prozesses. Die Variable now im obigen Beispiel bezieht sich auf Datum und Uhrzeit, zu der der Build zufällig ausgeführt wird. Und sobald wir die HTML-Dateien, die dieser Build erzeugt hat, hochgeladen haben, werden diese sich nicht ändern, bis wir den Build erneut ausführen. Das bedeutet, dass wir, sobald eine Veranstaltung in unserer Musikveranstaltungsstätte vorbei ist, den Build neu ausführen müssten, um sicherzustellen, dass die Website dies widerspiegelt.

Nun, wir könnten den Rebuild automatisieren, sodass er einmal täglich oder sogar einmal stündlich stattfindet. Genau das macht die CSS-Tricks Konferenz-Website über Zapier.

Dies könnte jedoch Build-Minuten kosten, wenn Sie einen Dienst wie Netlify verwenden, und es könnten immer noch Ausnahmefälle geben, in denen jemand eine veraltete Version der Website erhält.

Option 3: Logik am Edge durchführen

Edge-Worker sind eine Möglichkeit, Code auf CDN-Ebene auszuführen, wenn eine Anfrage eingeht. Sie sind zum Zeitpunkt der Erstellung dieses Artikels noch nicht weit verbreitet, aber sobald sie es sind, könnten wir unseren Datumsvergleich so schreiben

// 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), {})
}

Die Funktion render() würde unsere verarbeitete Veranstaltungsliste nehmen und in HTML umwandeln, vielleicht durch Einfügen in eine vorgerenderte Vorlage. Das große Versprechen von Edge-Workern ist, dass sie extrem schnell sind, sodass wir diese Logik serverseitig ausführen könnten, während wir dennoch die Leistungsvorteile eines CDNs genießen.

Und da der Edge-Worker jedes Mal ausgeführt wird, wenn jemand die Website anfordert, können wir sicher sein, dass er eine aktuelle Version davon erhält.

Option 4: Logik zur Laufzeit durchführen

Schließlich könnten wir unsere strukturierten Daten direkt an das Frontend übergeben, zum Beispiel in Form von Datenattributen. Dann schreiben wir JavaScript, das alle notwendigen Logiken auf dem Gerät des Benutzers ausführt und das DOM im laufenden Betrieb manipuliert.

Für unsere Musikveranstaltungs-Website könnten wir eine Vorlage wie diese schreiben

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

Dann führen wir unseren Datumsvergleich in JavaScript aus, nachdem die Seite geladen wurde

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

Die Variable now spiegelt die Zeit auf dem Gerät des Benutzers wider, sodass wir ziemlich sicher sein können, dass die Liste der Veranstaltungen aktuell ist. Da wir diesen Code auf dem Gerät des Benutzers ausführen, könnten wir sogar so weit gehen und Dinge tun, wie die Art und Weise, wie das Datum angezeigt wird, basierend auf der Sprache oder Zeitzone des Benutzers anzupassen.

Und im Gegensatz zu den vorherigen Punkten im Lebenszyklus dauert die Laufzeit so lange, wie der Benutzer unsere Website geöffnet hat. Wenn wir also wollten, könnten wir processEvents() alle paar Sekunden ausführen und unsere Liste würde perfekt aktuell bleiben, ohne die Seite neu laden zu müssen. Das wäre für die Website unserer Musikveranstaltungsstätte wahrscheinlich unnötig, aber wenn wir die Veranstaltungen auf einer Anzeigetafel vor dem Gebäude anzeigen wollten, könnte es nützlich sein.

Wo werden Sie die Logik platzieren?

Obwohl eines der Kernkonzepte von Jamstack darin besteht, dass wir so viel Arbeit wie möglich zur Build-Zeit erledigen und statisches HTML bereitstellen, können wir immer noch entscheiden, wo die Logik platziert werden soll.

Wo werden Sie sie platzieren?

Das hängt wirklich davon ab, was Sie tun möchten. Teile Ihrer Website, die sich kaum ändern, sind völlig in Ordnung, wenn sie zur Editierzeit fertiggestellt werden. Wenn Sie feststellen, dass Sie eine Information immer wieder ändern, ist es wahrscheinlich an der Zeit, diese in ein CMS zu verschieben und zur Build-Zeit abzurufen. Zeitkritische Funktionen (wie die hier verwendeten Veranstaltungsbeispiele) oder solche, die Benutzerinformationen benötigen, müssen wahrscheinlich weiter unten im Lebenszyklus am Edge oder sogar zur Laufzeit erfolgen.