Week 3

Nieuwe versie van de website publiceren via het CMS, links op de preview omgeving fixen, aanmaken van een formulier component

Deze week heb ik een drietal dingen gedaan:

1. Ervoor gezorgd dat je vanuit het CMS een nieuwe versie van de website kan publiceren

2. De links in de preview omgeving gefixt

3. Aanmaken van een formulier component

Een statische website handmatig laten updaten

Hoewel we dus voor een headless opzet hebben gekozen is het handig om vanuit een CMS een nieuwe versie van de website live te kunnen zetten zodat ook een content-editor de website kan updaten en we daarvoor niet een push op de master branch van GitHub hoeven te gooien.

In een headless opzet doe je dit door het gebruiken van Webhooks. Dit betekende dat we bij onze deployment service Vercel een hook hebben moeten aanmaken voor het live zetten van een nieuwe versie en dat we die hook op de één of andere manier moesten koppelen aan ons CMS zodat die vanuit daar geüpdatet kan worden.

Een webhook aanmaken bij Vercel

Binnen Vercel moesten we dus een webhook aanmaken, een webhook is simpelweg een URL waar naar een verzoek gedaan kan worden, als dit verzoek gedaan is wordt er een bepaalde taak uitgevoerd, in ons geval dus het updaten van de live website.

De final deploy hooks op Vercel.

Zoals je ziet is zo'n deploy hook dus niet meer dan een linkje. Nu rest ons nog om dat linkje op de één of andere manier te gebruiken in Storyblok.

De webhook implementeren in Storyblok

Ik ben direct gaan kijken of Storyblok al een bestaande oplossing hiervoor had. Die vond ik uiteindelijk bij al gebouwde Storyblok apps:

De Task-Manager app doet precies wat we nodig hebben.

Nadat ik dit had geïnstalleerd kwam er een tabje met 'Tasks' beschikbaar in de linker sidebar. Daar kon ik een nieuwe taak invullen, als een content-editor dan die taak zou uitvoeren wordt er simpelweg een verzoek gedaan naar de URL die ik heb ingevoerd:

Het aanmaken van een nieuwe task.

Zoals je in de achtergrond kan zien kan er bij een bepaalde task op 'execute' gedrukt worden waardoor te taak wordt uitgevoerd.

Fixen van links in de preview omgeving

De Storyblok preview omgeving maakt de linkjes standaard zoals de 'mappenstructuur' is. Wij hebben bijvoorbeeld een 'pages' map waar alle pagina's in staan. Echter, de pagina's worden gebouwd naar /pagina-naam. Dit zorgde in eerste instantie voor problemen in de preview omgeving omdat Storyblok daar zocht naar /pages/pagina-naam.

Dit heb ik daarom gefixt door het bouwen van een Nunjucks filter die we vervolgens kunnen gebruiken in de templates voor het bouwen van de pagina's:

// lib/filters/correct-page-slug.js
module.exports = (slug) => {
    return slug.includes('pages')
        ? slug.replace('pages', '')
        : slug
}

Het bovenstaande stukje code zorgt ervoor dat wanneer een slug van een bepaalde story 'pages' bevat dat deze dan verwijderd wordt. We zorgen er vervolgens in de template voor dat dit alleen gebruikt wordt als we in productie zitten:

---
<!-- rest van de metadata... -->
eleventyComputed:
    permalink: "{{ story.full_slug | correctPageSlug }}"
---

<!-- ...De pagina markup... -->

Bovenstaande stukje code gebruikt de correctPageSlug filter om de juiste permalink te gebruiken in productie. In development hoort het alsnog naar /pages/pagina-naam te gaan zodat de preview omgeving niet kapot gaat.

Aanmaken van een formulier component

Ondertussen hadden m'n teamgenoten alles zo opgezet dat we al bezig konden met het maken van componenten. Om onze use case te testen hadden we sowieso een formulier component nodig.

Zo konden we enerzijds aan de opdrachtgever tonen content-editors componenten en pagina's in elkaar konden zetten. Anderzijds maakte dit het mogelijk dat we in een later stadium nog wat nuttigs konden doen met het verwerken van formulieren in een headless opzet.

Formulier component aanmaken in het CMS

Zoals altijd beginnen we met het aanmaken van een nieuw component in het CMS. Dit omdat ik niet alleen persoonlijk van 'achter naar voren' werk, dus van de backend meer naar de front-end, maar ook omdat we dan aan de voorkant straks weten wat voor data we kunnen verwachten.

Uiteindelijk is een formulier enkel een blok met een aantal te kiezen velden. Elk veld moet dan weer een label hebben voor semantiek en wellicht een placeholder zodat content-editors een call to action aan kunnen geven. Ook moeten content-editors per veld kunnen kiezen wat voor veld het is (checkbox, textveld, wachtwoord, email etc.)

Uiteindelijk heb ik ervoor gekozen om het formulier zelf de volgende velden mee te geven:

• Een titel (wat kunnen gebruikers met dit formulier?)

• Velden (de input velden binnen het formulier)

• Verstuurtekst (wat wil je als call to action hebben?)

Om het voor content-editors overzichtelijker te maken heb ik de elementen in 'fields' beperkt tot een form-input en een textarea zodat een content-editor daar alleen maar één van die opties te kiezen heeft.

Datzelfde heb ik uiteindelijk gedaan voor de blokken op een pagina, daar kunnen editors alleen maar kiezen uit cmd-components. In ons geval is dat alleen nog maar een formulier zoals onderstaand te zien is (en dat terwijl form-input en textarea eigenlijk ook componenten zijn):

Alleen het Form is hier beschikbaar als een block in de pagina content

Formulier component in de front-end

Naast dat we het moeten bouwen in het CMS moet het natuurlijk ook zo zijn dat we het formulier beschikbaar maken in de front-end, right? Dit kunnen we eenvoudig doen door een HTML bestand aan te maken voor dit component. Omdat het een formulier is kunnen we ook de velden weer apart wegstoppen in kleinere componenten.

Het formulier component kunnen we vervolgens in het eerder gecreëerde modular-content component weer ophalen als het block van het type form is zodat het ook weer goed op de pagina terecht komt.

<!-- src/site/_includes/components/form/form.html -->
{% from "./fields/form-input.html" import formInput %}
{% from "./fields/form-textarea.html" import textArea %}
{% from "./fields/form-dropdown.html" import dropdownInput %}
{% from "./fields/form-upload.html" import uploadInput %}
{% from "./fields/form-checkbox.html" import checkboxInput %}
{% from "./fields/form-radio.html" import radioInput %}
{% from "../button/button.html" import component as button %}

{% macro component(form) %}
  <form class="app-form">
    {% if form.title %}
    <p>{{ form.title }}</p>
    {% endif %}

    {% for field in form.fields %}
      {% if field.component === "Form input" %}
        {{ formInput(field) }}
      {% endif %}

      {% if field.component === "Form textarea" %}
        {{ textArea(field) }}
      {% endif %}

      {% if field.component === "Form dropdown" %}
        {{ dropdownInput(field) }}
      {% endif %}

      {% if field.component === "Form upload button" %}
        {{ uploadInput(field) }}
      {% endif %}

      {% if field.component === "Form checkbox" %}
        {{ checkboxInput(field) }}
      {% endif %}

      {% if field.component === "Form radio button" %}
        {{ radioInput(field) }}
      {% endif %}
    {% endfor %}

    <button type="submit">{{ form.submit_text }}</button>
  </form>
{% endmacro %}

Je ziet dus dat we constant checken wat het component is wat in een bepaald veld gebruikt wordt, afhankelijk daarvan renderen we het juiste input veld. Dit geeft de content-editor de complete vrijheid om de volgorde van de velden aan te passen en geeft ons de vrijheid om eenvoudig nieuwe velden toe te voegen.