Astro... een 'Static site builder' met interessante extra’s 🚀

Blog

Het lijkt vaak wel of er wekelijks nieuwe tools en frameworks uitkomen, en het is dan ook vaak keuzes maken als je bij wilt blijven.

Maar soms zijn er ook nieuwe ontwikkelingen die de kleinere beslissingen als kiezen tussen React of Vue overstijgen. Astro is zo’n ontwikkeling.

Wat is Astro?

Astro is een Static site builder, en dat is op zich niets bijzonders. Wat echter wél bijzonder is, is dat het Astro echt niets uitmaakt wat je in je Static site wil opnemen. Dus als je al een mooi navigatie-component hebt gebouwd in Vue, en een formulieren-component in React; het kan allemaal!

Astro is naast een builder eigenlijk ook een bundler, net zoals Webpack of Vite, maar dan heel erg slim. Zo is het mogelijk om een applicatie te bouwen met de bekende JavaScript-frameworks zonder dat er links naar de JavaScript-files nodig zijn. Je hoeft dan dus geen react.js in te laden, omdat deze al is gebundeld in het pakketje dat Astro voor je gemaakt heeft.

Inmiddels zijn er ook grote bedrijven die gebruik maken van Astro. Dit zijn onder andere Google, Trivago en Netlify.

Wat maakt Astro uniek?

Voordat ik uit kan leggen wat Astro bijzonder maakt, moet ik iets uitleggen over Renderen. Hiermee wordt bedoeld: hoe (en waar) wordt de pagina in elkaar gezet?

Er zijn een aantal render-varianten mogelijk:

  1. Client-side Rendering (de pagina wordt samengevoegd op het device van de gebruiker)
  2. Server-side Rendering (de pagina wordt samengevoegd op de server en dan naar de gebruiker gestuurd)
  3. Partial Hydration (de combinatie van de eerder genoemde varianten) de pagina wordt eerst geladen, en vervolgens wordt de inhoud ververst door nieuwere content)

Maar wat Astro nu onderscheidt, is dat het niet alleen mogelijk is om deze renderings-mogelijkheden toe passen per hele pagina, maar ook per eilandje (gedeelte van een pagina). Dit wordt dan ook wel Island Architecture genoemd. Stel je voor dat je op een homepage naast statische componenten als een header en een footer, ook informatie wilt tonen die dynamisch is en misschien langer duurt om binnen te halen. Een voorbeeld hiervan zie je in de afbeelding hieronder.

Astro heeft hier een specifieke syntax voor:

  1. client:load Als een component wordt geladen zonder client attribuut, dan worden ze toegevoegd zonder JavaScript. Mocht je een component willen laden met JavaScript, dan is ieder geval een client:load noodzakelijk.
  2. client:idle Voor componenten met lage prio. Deze worden pas gerenderd op het moment dat het initieel laden van de pagina klaar is.
  3. client:visible een variant op idle, maat dan met lazy loading. Component wordt pas geladen wanneer het in beeld komt.
  4. client:media Voor componenten die alleen zichtbaar zijn als een media query van toepassing is: bijvoorbeeld alleen op schermen smaller dan 400px.
  5. client:only Zorgt er voor dat een component niet aan de server-side wordt gerenderd, maar alleen aan de client-side.

Wie zijn de concurrenten van Astro?

Concurrenten voor Astro zijn onder te verdelen in 2 groepen: frameworks en bundlers. In de eerste categorie zijn de grootste concurrenten waarschijnlijk NextJS en NuxtJS. Dit zijn vergelijkbare frameworks (NextJS op basis van React, en NuxtJS op basis van VueJS), die beiden mogelijkheden bieden voor Static Site Generation en Server Side Rendering. Het allergrootste verschil met Astro is dat:

  1. Astro stelt je in staat te kiezen welk framework je wil gebruiken, of zelfs wil combineren
  2. Partial hydration is bij Astro standaard. Bij andere frameworks is dit natuurlijk wel mogelijk maar niet direct out-of-the-box
  3. Builds van Astro zijn doorgaans kleiner dan die van de concurrenten door een rigoureuze aanpak van JavaScript files.

Astro zegt in zijn documentatie ook nog het een en ander over het verschil tussen Astro en enkele andere alternatieven zoals

Conclusie 🥁

Astro’s mogelijkheid om een applicatie te maken met JavaScript frameworks, die standaard wordt geleverd zónder JavaScript is verfrissend. Mocht je applicatie het wel nodig hebben dan laad je die gewoon in geef je die juiste client methode mee.

Zelf denk ik dat Astro heel interessant is. Juist omdat je verschillende frameworks kunt combineren, of via Astro als middenlaag stapsgewijs over kunt van het ene framework naar het andere. Astro groeit zowel in adaptatie door de Front-End community als in volwassenheid: Juni 2022 kom Astro uit bèta met de release van Astro 1.0.

In ieder geval; Ik houd Astro de komende tijd zeker in de gaten. Jij ook, en kan ik (of één van mijn collega’s) je helpen bij de implementatie? Laat het ons weten!

Johan
Auteur Johan Developer

Heb je vragen over dit onderwerp of zou je Johan willen inhuren voor een vergelijkbare opdracht?

Neem contact met ons op

Gerelateerde artikelen

Raymon Raymon / 21-03-2022

7 minuten lezen

Om te beginnen: wat is end-to-end testen? We hebben twee zogeheten ‘ends’ in een webapplicatie: de Front-End en de Back-End. Met unit-testing testen we de code voor ofwel de Front-End ofwel de Back-End. We testen niet hoe de applicatie zich gedraagt in de browser of hoe beide ends samenwerken.

Begrijp me niet verkeerd: ik ben voorstander van unit tests! Maar het is net zo belangrijk om te testen hoe de Front-End en de Back-End samenwerken.

Met end-to-end testen kijk je of de Front-End goed samenwerkt met de Back-End. Zo moet bijvoorbeeld het automatisch invullen van formulieren worden getest met een end-to-end test, maar ook het klikken op knoppen en het navigeren door de pagina’s.

Deze end-to-end tests controleren dus of de Front-End de gegevens vanuit de Back-End correct verwerkt.

Wat is Cypress?

Er zijn veel end-to-end testtoolkits, maar een van de meest populaire en snelste toolkits is Cypress.

Cypress biedt een manier om end-to-end tests te schrijven met JavaScript en de testrunner. Daarnaast biedt het de mogelijkheid om screenshots en video’s op te slaan wanneer een test mislukt. En, waar de meeste organisaties blij van worden: het is open-source. En dat is geweldig.

End-to-end testen met Cypress

In de Cypress-documentatie staat een geweldige tutorial waarin je op weg wordt geholpen bij het schrijven van end-to-end-tests.

Stap 1: configureren

Stap 1: configureren

Aan de basis van het project bevindt zich een cypress.json, waar je enkele standaardconfiguraties kunt wijzigen. In ons project ziet het er als volgt uit:

 

{
    "testFiles": "**/*.e2e.test.js",
    "chromeWebSecurity": false
}


In de property testFiles vertellen we Cypress om te zoeken naar bestanden die e2e.test.js in de naam bevatten. Je kunt Cypress configureren met TypeScript, maar in dit geval denk ik dat dat geen toegevoegde waarde heeft. Het vereist een extra transpilatie-stap die langer duurt.

Stap 2: testbestanden opslaan

Stap 2: testbestanden opslaan

Bij unit-testing is het heel gebruikelijk om de tests op te slaan in de componentmappen. In dit geval neemt Cypress de map cypress/integration als root om naar de bestanden te zoeken. We hebben dus een structuur die gebaseerd is op de applicatie zelf, waarin we de end-to-end testbestanden opslaan.

Stap 3: de test voorzien van minimale eisen

Stap 3: de test voorzien van minimale eisen

Elke test heeft ten minste een function describe() met daarin ten minste één it() function. Dit werkt op dezelfde manier als het schrijven van unit-tests:

 

describe('My First Test', () => {
  it('Does not do much!', () => {
    expect(true).to.equal(true)
  })
})


Dit voorbeeld lijkt op een unit-test. We moeten dus gebruik maken van de Cypress Library. Je kunt dat gebruiken door cy te gebruiken zoals in het onderstaande voorbeeld, waarin we https://example.cypress.io bezoeken.

 

describe('My First Test', () => {
  it('Visits the Kitchen Sink', () => {
    cy.visit('https://example.cypress.io')
  })
})


Je kunt zien dat de echte browser deze actie uitvoert door npm run e2e:open uit te voeren.

Onze scripts in de package.json zien er als volgt uit:

 

{
//...
"e2e:run": "npx cypress run --config-file cypress.json",
"e2e:open": "npx cypress open --config-file cypress.json",
"e2e:open:edge": "npx cypress open --browser edge --config-file cypress.json",
"e2e:open:firefox": "npx cypress open --browser firefox --config-file cypress.json"
//...
}


Cypress start de toepassing en daar kan je de end-to-end-test selecteren die je wilt uitvoeren. Standaard wordt de Chrome-browser geopend, maar er is ook een optie om het in Firefox of Edge uit te voeren.

Cypress biedt een complete bibliotheek en je kunt de documentatie raadplegen voor meer informatie hierover.

Stap 4: testen!

Stap 4: testen!

We zullen vooral zaken die in de browser verschijnen of veranderen testen met end-to-end tests. Een eenvoudig scenario: we bezoeken pagina x en controleren of de h1 de tekst “Dit is een geweldige titel” bevat.

 


describe('My First Test', () => {
  it('Visits the Kitchen Sink', () => {
    cy.visit('https://example.cypress.io');
    cy.get('h1').should('contain.text', ' Dit is een geweldige titel');
  })
})


In dit voorbeeld maakt elke methode die je aanroept vanuit de cy-bibliotheek deel uit van het testen. Zo zal cy.visit() de actie uitvoeren, maar als er geen geldige pagina op die URL staat, zal de test niet slagen. Dus met elke actie die je uitvoert, begin je een ‘assertion’.

In Cypress zijn er twee verschillende soorten ‘assertions’. should() of and() zijn “Implicit Subjects”. .expect is een “Explicit Subject”. Lees hier meer over in de Cypress-documentatie.

Bij het aanroepen van cy.get(‘h1’) zal het zoeken naar de H1-tag. Wanneer het dat element vindt, gaat de test verder. De test zal falen indien het element niet binnen een paar milliseconden wordt gevonden. Na de get-method kun je een heleboel andere methoden koppelen, zoals:

  • .contains() verwacht dat het element met inhoud uiteindelijk in de DOM zal bestaan.
  • .find() verwacht ook dat het element uiteindelijk in de DOM zal bestaan.
  • .type() verwacht dat het element uiteindelijk in een typbare staat zal zijn.
  • .click() verwacht dat het element zich uiteindelijk in een bruikbare staat bevindt.
  • .its() verwacht uiteindelijk een property over het huidige onderwerp te vinden.

Dus wat testen we met end-to-end-tests?

  1. Of een element een bepaalde klasse heeft (cy.get(‘element.selector’).should(‘have.class’, ‘ng-valid’); ) of juist niet (cy.get(‘element.selector’).should(‘not.have.class’, ‘ng-valid’);).
  2. Of een lijst 3 onderliggende elementen heeft ( cy.get(‘ul > li’).should(‘have.length’, 3); ).
  3. Controleren of een invoerveld of tekstgebied een bepaalde waarde heeft ( cy.get(‘input[name=“firstName”]’).type(‘Santa Claus’).should(‘have.value’, ‘Santa Claus’); ).

Bekijk deze lijst met voorbeelden van wat je kunt gebruiken in de should-method.

Extra voorbeeld:

Je kunt de context van een bovenliggend element toevoegen om assertions uit te voeren, wat handig is bij formulieren.

 

<form>
  <input name="email" type="email" />
  <input name="password" type="password" />
  <button type="submit">Login</button>
</form>

describe('My First Test', () => {
  it('Visits the Kitchen Sink', () => {
    cy.visit('https://example.cypress.io');
    cy.get('form').within(($form) => {
        // you have access to the found form via
        // the jQuery object $form if you need it

        // cy.get() will only search for elements within form,
        // not within the entire document
        cy.get('input[name="email"]').type('john.doe@email.com')
        cy.get('input[name="password"]').type('password')
        cy.root().submit()
    })
  })
})


Kijk voor meer voorbeelden van de within()-method in de Cypress-documentatie.

Herbruikbare functionaliteit

In het geval van herbruikbare acties die je keer op keer uitvoert, kan je eenvoudige functies schrijven die je in een lib-map kunt plaatsen. Maar Cypress biedt een gebruiksvriendelijkere manier om dit te doen. Dit wordt “custom commands” genoemd; hiervan kan je veel voorbeelden vinden in de documentatie.

Maar een van de beste voorbeelden is het schrijven van de command voor de login. Je moet die code toevoegen aan het bestand cypress/support/commands.js.

 

Cypress.Commands.add('login', (userType, options = {}) => {
  // this is an example of skipping your UI and logging in programmatically

  // setup some basic types
  // and user properties
  const types = {
    admin: {
      name: 'Jane Lane',
      admin: true,
    },
    user: {
      name: 'Jim Bob',
      admin: false,
    },
  }

  // grab the user
  const user = types[userType]

  // create the user first in the DB
  cy.request({
    url: '/seed/users', // assuming you've exposed a seeds route
    method: 'POST',
    body: user,
  })
    .its('body')
    .then((body) => {
      // assuming the server sends back the user details
      // including a randomly generated password
      //
      // we can now login as this newly created user
      cy.request({
        url: '/login',
        method: 'POST',
        body: {
          email: body.email,
          password: body.password,
        },
      })
    })
})


Conclusie

Nu is het aan jou om geweldige end-to-end tests te schrijven met Cypress! Perfecte tests bestaan niet, maar als je ze elke keer een beetje optimaliseert, wordt het je ‘source of truth’. De end-to-end-tests zijn geweldig voor developers om uit te voeren na het bouwen van een nieuwe functie of het wijzigen van een bestaande, omdat het onmogelijk is om alle testscenario’s te onthouden.

Veel succes en plezier met het schrijven van waardevolle end-to-end tests! Als we je hierbij kunnen helpen, doen mijn collega’s en ik dat natuurlijk graag.

/ 24-02-2022

2 minuten lezen

Hoe gaaf zou het zijn om een applicatie te draaien in een omgeving die zich continu op basis van de behoefte uitbreidt of zelfs verkleint? Een omgeving die volledig geautomatiseerd als een mechanisme functioneert en dynamisch is? De wereld van hedendaagse containers en microservices is een oplossing die dit kan waarmaken. Dit wordt mede mogelijk gemaakt door Kubernetes (in het Grieks “stuurman (iemand die aan het roer staat) of piloot”).

Traditionele datacentertechnieken waarbij elke applicatie op een afzonderlijke virtuele machine draait, vragen veel kracht en brengen zo hoge kosten met zich mee. Kubernetes daarentegen is een orchestrator die de onderliggende container-virtualisatie-software (Docker) aan het managen is. Het opspinnen of opschalen van een container duurt in veel gevallen enkele seconden, omdat het alleen een container hoeft op te spinnen in plaats van eerst een systeem met daaropvolgend de applicatie. Op het gebied van schaalbaarheid en performance zorgt deze oplossing voor een efficiënt applicatielandschap.

Kubernetes fungeert als orchestrator

Wat moet je je voorstellen bij Kubernetes?

Je kunt het eigenlijk vergelijken met een zeehaven waar de Docker Nodes de containerschepen zijn en dat Kubernetes de kranen, geautomatiseerde voertuigen en opslag van de containers in de haven beheert. Op basis van de vraag naar containers breidt Kubernetes de omgeving uit en plaatst dit zelf op de schepen (Docker Nodes). Het plaatsen van de containers wordt bepaald door de configuratie van de orchestrator.

Het is te vergelijken met een zeehaven

Een oplossing die zelfs Kubernetes automatiseert

Hoe mooi zou het zijn om zelfs Kubernetes te automatiseren? Om dit gemakkelijker te maken heeft Microsoft een mooi laagje over het hele Kubernetes platform gebouwd: AKS (Azure Kubernetes Services). AKS is een samenstelling van de Operating System, Virtualisatie Software (Docker) en Orchestrator (Kubernetes). Dit maakt deployment en management on the go mogelijk. Vanuit de Azure portal is het mogelijk om met een aantal drukken op de knop een volledige Kubernetes cluster uit te rollen.

Je vraagt je dan misschien af hoe het zit met de configuratie. Die zijn simpel in te laden door parameter files en de meest belangrijke opties zijn al aan te passen via de Web interface. Zoals het opschalen van de nodes en het verkrijgen van nuttige informatie over de workload (pods), nodes (workers), networking, security en identity and access management van de omgeving.

Dit was het even in het kort over Kubernetes. De volgende keer gaan we dieper in op verschillende onderdelen. Mochten mijn collega’s en ik je in de tussentijd kunnen helpen bij het werken met Kubernetes of een ander vraagstuk binnen Azure, laat het ons weten. We helpen graag!

Wietze Wietze / 01-12-2021

5 minuten lezen

Front-End developers weten dat de ontwikkeling van Front-End technieken nooit stil staat. De ontwikkeling van frameworks als React, Vue, Angular en Svelte is de laatste jaren flink gegroeid. Daarnaast komen er steeds vaker handige tools beschikbaar die het leven van een frontender net iets makkelijker kunnen maken. Deze keer kijken we naar Storybook en wat de meerwaarde hiervan kan zijn zowel voor een developer als voor andere disciplines. In eerste plaats moeten we weten wat Storybook is, en waar het voor gebruikt kan worden.

Wat is Storybook?

Het maken en onderhouden van een style guide is over het algemeen een uitdaging. Storybook is een open source framework dat het eenvoudiger maakt om de user interface van projecten te bouwen, documenteren, testen en demonstreren.

Storybook kan gebruikt worden als playground voor UI componenten. Doordat Storybook zelf buiten de applicatie draait, kunnen we het gedrag van de componenten in Storybook aanpassen naar een gewenste situatie, zonder dat dit invloed heeft op de componenten in de applicatie.

De huidige versies van Storybook ondersteunen functionaliteiten die een groot aantal onduidelijkheden in de moderne workflow voor webontwikkeling opvult.

Storybook ondersteunt de meest gangbare Front-End frameworks van het moment zoals React, Vue en Angular, maar is ook vanuit native JavaScript te gebruiken.

Wat is de story van Storybook?

Uit de behoefte om componenten in een geïsoleerde omgeving te kunnen definiëren, developen en de UI te kunnen testen, begon Storybook in april 2016 met een eerste release van versie 1.0 vanuit de Kadira startup (de originele developer van Storybook), waarna in september van het zelfde jaar versie 2.0 vrijgegeven werd.

Na dat de startup werd stopgezet en het project dood werd verklaard, volgde er een korte break en werd het project in 2017 door de open source verder omarmd. Inmiddels is versie 6.3 gereleased (juni 2021). De hele storybook story is te vinden op https://storybook.js.org/blog/the-storybook-story/

Storybook stopgezet door Kadira

Ondertussen hebben ze meer dan 10.000 github stars en 290k maandelijkse downloads.

Wie kunnen Storybook gebruiken en hoe?

Developers binnen het team zullen Storybook gebruiken als werkruimte om componenten op dezelfde manier neer te zetten. Een voordeel is dan ook dat de opgedane kennis van Storybook te gebruiken is bij elk framework dat momenteel door Storybook ondersteunt wordt.

Storybook kan opengesteld worden voor externe developers, wat interessant kan zijn voor open source ontwikkeling. Hiervoor kan Storybook vooral ingezet worden als documentatie waarbij de API van de componenten wordt uitgelegd.

Voor UX/UI designers kan Storybook als onderdeel dienen van hun design system met koppelingen naar o.a. Frontify waardoor het als gemeenschappelijk bron kan dienen. Als er aanpassingen gedaan moeten worden of er een nieuw component ontwikkeld is, hebben ze gelijk alle (nieuwe) componenten tot hun beschikking

Naast dat het documentatie oplevert, heeft het nog een voordeel dat de stakeholders sneller een nieuwe component kunnen beoordelen op het design en functionaliteit en niet afhankelijk zijn van een nieuwe release. Ook kan Storybook gebruikt worden voor verdere communicatie binnen of buiten het bedrijf.

Om Storybook te gebruiken binnen een project, moet er wel rekening gehouden worden met het gekozen framework van het project. Zo zal de installatie en de structuur/syntax voor React net iets even anders zijn dan voor bijvoorbeeld Vue of Angular.

Storybook is gebaseerd op componenten: maak daarom componenten zo compact mogelijk. Terwijl een project groeit met steeds meer componenten, is het verstandig om de volgende richtlijnen te hanteren:

  • Je codeert de stories in Storybook om een component weer te geven, maar het kan ook op zichzelf documentatie worden over hoe het component te implementeren is.
  • Heldere en duidelijke code. Het doel is om te begrijpen hoe je het component kunt gebruiken zonder te veel na te denken.
  • Om dit te doen, probeer zo statisch mogelijk te zijn: vermijd abstracties, herhaal indien nodig, vermijd elk soort algoritme.
  • Een juiste benaming en locatie van je story, zodat deze overeenkomt met je codebase

Op het eerste gezicht lijkt Storybook alleen te zijn bedoeld voor zo gezegd ‘domme componenten’ die alleen gebruikt worden voor de user interface. Door de complexere componenten te isoleren en business logica te verminderen, kunnen deze echter prima binnen Storybook gebruikt worden waarbij de focus verlegd wordt van de functionaliteit naar het component zelf.

​Storybook addons

In de basis is Storybook vrij compleet, maar dat wil niet zeggen dat we er niet meer mee kunnen doen. Daarom zijn er tal van addon’s voor te vinden die net even dat stukje extra functionaliteit kunnen geven.

Populaire addons

Een aantal veel gebruikte addons zijn:

  • Links - dit kan gebruikt worden om componenten onderling te verbinden om demo’s of prototypes mee te maken.
  • Viewport - met Storybook Viewport Addon kunnen jouw verhalen in Storybook in verschillende formaten en lay-outs worden weergegeven. Dit helpt bij het bouwen van responsieve componenten in Storybook.
  • Actions – geeft data weer in de UI na het uitvoeren van een event handler
  • Accessibillty - test je componenten tegen de huidige webstandaard
  • Docs – standaard heeft elke story al een DocsPage. Mocht deze niet voldoende zijn kan er gebruik gemaakt worden van deze addon waarna er meer mogelijkheden zijn voor documentatie

Conclusie

Storybook kan optimaal functioneren als het gebruikt wordt door developers, UX/UI developers en de stakeholders. Door combinatie van deze verschillende disciplines levert Storybook een grote meerwaarde voor het ontwikkelen en het onderhouden van webapplicaties.

Zelf aan de slag?

Wil je zelf aan de slag met Storybook, maar kan jouw team wel iemand gebruiken die hier ervaring mee heeft? Mijn mede-frontenders bij ShareValue en ikzelf hebben hier ervaring mee, werken graag met Storybook en komen dan ook graag jouw team helpen bij het opzetten hiervan.

Bronnen

Storybook: https://storybook.js.org/

Addons: https://storybook.js.org/addons

Storybook Story: https://storybook.js.org/blog/the-storybook-story/

{description}

Hoor van onze experts hoe leuk ShareValue is

Lees de verhalen van onze collega's
{description}

Heb je een Front-End Developer nodig?

Neem contact met ons op