Iteratieslagen

Een beschrijving van de belangrijkste iteraties die we hebben doorgevoerd en uitkomsten. Wat leidde ertoe en wat was de uitkomst?

CMS (Storyblok)

• We hebben de folder structure gewijzigd (wat werkt het beste?) --> algemene layout van gehele pagina's in 'pages', navigatie in 'navigation' en de verdere content in aparte mappen (zoals: 'Events').

• We hebben de previewmodus gewijzigd

• We hebben 'preview templates' toegevoegd aan de componenten (waardoor je de content van een component in de visual editor kan zien)

• We hebben de user roles aangepast

• We hebben de filenames en componenten in het CMS vertaald naar het Nederlands

Styling

Layout homepage

Veelal from scratch wat placeholdertext gebruikt om de functionaliteiten mee te testen.

Dit hebben wij uiteraard wel rechtgetrokken na het applyen van de algehele styling.

Layout evenementenoverzichtspagina

Layout header

Layout evenementenpagina

Code iteraties

Het bouwen van een preview omgeving

Om aan content-editors te kunnen tonen welke aanpassingen ze aan het doen zijn is het handig om direct feedback te tonen (iets wat uiteindelijk ook terug kwam uit de user test, waarover je later meer kan lezen). In eerste instantie hadden we ervoor te kozen om hier veel te leunen op JavaScript zodat je dus live die aanpassingen kan tonen. Echter, dit maakte dat we elk component twee keer moesten bouwen als het ware, eenmaal in HTML/Nunjucks en eenmaal als Javascript component waardoor je de volgende situatie kreeg:

// src/assets/js/preview-environment/components/button.js
export default ({ _editable, text, type, link }) => {
  if (type === 'button') {
    return `
    <button class="button">
      ${text}
    </button>
  `
  } else {
    return `
    <a class="button" href="${link.url}">
      ${text}
    </a>
    `
  }

}

{% macro component(item) %}
  {% if item.type === "button" %}
    <button class="button">
      {{ item.text }}
    </button>

    {% else %}
    <a class="button" href="{{ item.link.url }}">
      {{ item.text }}
    </a>

  {% endif %}
{% endmacro %}

Hoewel dit maakte dat de preview omgeving inderdaad live kon updaten maakte het dat we de website als het ware moesten hijacken met JavaScript zodra het in de preview omgeving zit.

Dat is natuurlijk iets wat mogelijk is maar dit zorgt voor veel extra werk voor developers en dat is iets wat we willen vermijden om de drempel voor nieuwe developers laag te houden. Daarom hebben we besloten dat we met een andere oplossing moesten komen. Het eerste waar we op kwamen is het aanmaken van een aparte preview branch die dan vanuit het CMS te updaten is.

Een aparte preview branch

Te updaten vanuit een webhook vanuit het CMS

Echter, dit zorgde ervoor dat een content-editor bij elke aanpassing die hij of zij wilt zien vanuit de pagina waar die aan bezig is naar de tasks moet binnen het CMS, op 'deploy preview' moet klikken, 30 seconden moet wachten om vervolgens de pagina te refreshen. Dit zorgt voor de content-editor weer voor heel veel extra overhead. Onze laatste oplossing was dat we op de preview branch ervoor zorgden dat de preview branch wordt geüpdatet wanneer een content-editor op 'save' klikt. Ook komt er dan een melding in beeld en refresht de pagina na 30 seconden:

Gebruiker krijgt een melding nadat hij/zij op 'save' klikt

De opzet van modular content

Het modular-content component is misschien wel het belangrijkste component van de hele website. Hierin kunnen namelijk alle componenten ingeladen worden vanuit het CMS en weergegeven worden op een pagina. In eerste instantie hadden we een component gebouwd met veel ifjes in de layout om zo te kunnen bepalen welke elementen getoond worden (zie onderstaande snippet).

<!-- If-statements in de layout -->
{% from "components/test-component.html" import testComponent %}

{% macro modularContent(content) %}
  <div class="modular-content" id="modular-content">
    {% for item in content %}

    {% if item.component === "Test component" %}
      {{ testComponent(item) }}
    {% endif %}

    {% endfor %}
  </div>
{% endmacro %}

Als je weinig componenten hebt is dit nog overzichtelijk. Echter toen we meer componenten kregen liepen we er tegenaan dat het voor de developer onoverzichtelijk wordt met al die if-statements in de markup. Daarom heeft Gijs toentertijd een slimmere oplossing gebouwd waar elk component een soort slug mee kreeg van welke map het component in te vinden is. Hierdoor hoefden we in de markup alleen maar te loopen over de content en konden we de componenten dynamisch importeren en implementeren:

{% macro modularContent(content) %}
  <div class="modular-content" id="modular-content">
    {% for item in content %}

    {% if item._editable %}
    <!-- {{ item._editable }} -->
    {% endif %}

    {# site.js creates a slug from the component name. #}
    {% from "components/" + item.componentSlug + "/" + item.componentSlug + ".html" import component %}
    {{ component(item) }}
    {% endfor %}
  </div>
{% endmacro %}

Hoewel de bovenstaande oplossing voorkwam dat we allemaal if-statements in de markup hadden staan maakte het wel dat we elk component moesten behandelen als een macro die we dan altijd component moesten noemen, dit maakt dat je het nog duidelijker zou moeten documenteren.

Ook zorgde dit ervoor dat als iemand in Storyblok een component zou maken en implementeren in een pagina maar het HTML bestand niet bestaat binnen de codebase dat dan de build faalt, ook wanneer je slechts aan het developen bent. Dit zorgt ervoor dat de workflow stroperig wordt wanneer je met meerdere mensen tegelijk aan het ontwikkelen bent.

Uiteindelijk hebben we daarom gekozen om terug te gaan naar de if-statements oplossing omdat we toch vonden dat dit de meest duidelijke manier is om de componenten te implementeren zonder dat er veel 'magie' under the hood gebeurt, het ziet er nu als volgt uit:

{% macro modularContent(content) %}
  <div class="modular-content" id="modular-content">
    {% for item in content %}

    {% if item._editable %}
    <!-- {{ item._editable }} -->
    {% endif %}

    {% if item.componentSlug === 'events' %}
      {% from 'components/events/events.html' import component %}
      {{ component(item) }}
    {% endif %}

    {% if item.componentSlug === 'hero-header' %}
      {% from 'components/hero-header/hero-header.html' import component %}
      {{ component(item) }}
    {% endif %}

    {% if item.componentSlug === 'image-text' %}
      {% from 'components/image-text/image-text.html' import component %}
      {{ component(item) }}
    {% endif %}

    {% if item.componentSlug === 'form' %}
      {% from 'components/form/form.html' import component %}
      {{ component(item) }}
    {% endif %}

    {% if item.componentSlug === 'button' %}
      {% from 'components/button/button.html' import component %}
      {{ component(item) }}
    {% endif %}

    {% if item.componentSlug === 'latest-events' %}
      {% include('components/latest-events/latest-events.html') %}
    {% endif %}

    {% if item.componentSlug === 'assessment_elements' %}
      {% from 'components/assessment_elements/assessment_elements.html' import component %}
      {{ component(item) }}
    {% endif %}

    {% if item.componentSlug === 'description_list' %}
      {% from 'components/description_list/description_list.html' import component %}
      {{ component(item) }}
    {% endif %}


    {% endfor %}
  </div>
{% endmacro %}

Dit maakt dat we niet alleen macro's hoeven te gebruiken maar dat we ook componenten kunnen 'includen', dit is eveneens iets waar we tegenaan liepen met de vorige oplossing.