Wat speelt er nu bij ShareValue?

Sem Sem / 13-09-2022

6 minuten lezen

De laatste jaren vindt er een transitie plaats op het gebied van mobile development. Steeds vaker kiezen bedrijven ervoor om hun mobiele applicaties niet langer in Java (voor Android) of Swift (voor iOS) te ontwikkelen, maar kiezen zij voor een hybride framework als basis voor hun mobiele applicatie. In deze blog beschrijf ik één van deze frameworks, namelijk Ionic. Wat is Ionic, hoe werkt het en waarom zou jij de transitie moeten maken naar een native web-framework voor het ontwikkelen van mobiele applicaties.

Wat is Ionic?

Ionic is een open source interface platform waarmee mobiele en desktop-applicaties ontwikkeld kunnen worden met gebruik van web-technologieën als HTML, CSS en JavaScript. Deze toolkit wordt nauw geïntegreerd met een populair Front-end JavaScript framework naar keuze, zoals Angular, Vue en React. In andere woorden maakt Ionic het mogelijk om jouw webapplicatie voor verschillende platforms te ontwikkelen vanuit één codebase en daarbij gebruik te maken van de native functionaliteiten van de apparaten waarop de applicatie draait. Omdat Ionic apps gebaseerd zijn op het web, kun je ook verschillende web-gebaseerde UI libraries gebruiken zoals TailwindCSS of Bootstrap voor de opmaak van je applicatie.

Ionic maakt gebruik van Capacitor. Capacitor is een cross-platform native runtime die verschillende web-gerichte API’s biedt. Daarmee kan de app zoveel mogelijk web standaarden blijven gebruiken en heeft daarbij toegang tot de uitgebreide systeemeigen apparaat-functies. Denk hierbij bijvoorbeeld aan het gebruik van bluetooth, locatie, push notificaties, batterijstatus, opslag en de camera.

Waarom wil je Ionic gebruiken?

Ionic biedt de gebruiker een naadloze ervaring, waar de gebruiker zich ook bevindt. Of dat nu op een telefoon is, op een desktop of in de browser; de gebruiker verwacht consistentie via alle kanalen. Door het gebruik van Ionic kan met een enkele codebase voor al deze kanalen een applicatie uitgerold worden.

Door met Ionic te bouwen, kun je je bestaande web-ontwikkelaars inzetten voor het bouwen van mobiele- en desktop applicaties. Je hoeft niet langer op zoek naar een aparte ontwikkelaar voor ieder platform dat je wilt ondersteunen. De web-ontwikkelaars ontwikkelen de applicatie in Ionic en rollen deze zonder problemen uit naar de verschillende platformen.

Naast bovengenoemde voordelen is Ionic ook nog eens open-source en dus helemaal gratis. Ionic heeft een grote community en vraagstukken waar je als ontwikkelaar tegenaan loopt worden dan ook veel besproken op de verschillende ontwikkelforums. Daarnaast integreert Ionic heel gemakkelijk met bekende tools (bijvoorbeeld met Azure), zodat het uitrollen van applicaties naar de Google Play Store of Apple App Store heel eenvoudig wordt.

Hoe werkt Ionic?

Een native functionaliteit is door het gebruik van Capacitor eenvoudig in een Ionic-app toe te voegen. Zo kunnen we bijvoorbeeld de locatie van ons toestel gebruiken. Als eerst moeten we een nieuwe Ionic applicatie genereren. Dit kunnen we zelf doen via de command-line Interface die Ionic biedt, of via een handige web-interface.

Figuur 1 - Web-interface voor het opzetten van een Ionic-applicatie.

In dit voorbeeld maken wij de applicatie met de CLI. Eerst zorgen we ervoor dat Ionic globaal op onze computer geïnstalleerd is en daarna starten we het initialisatie proces.


$ npm install -g @ionic/cli

$ ionic start

De Ionic-CLI vraagt ons nu een aantal dingen te kiezen voor ons project, zoals welk framework en welke basis-lay-out wij willen in onze app? In mijn voorbeeld kies ik voor Angular met een `blank` applicatie-lay-out, maar andere opties zijn een lay-out met tabbladen of met een menu. De eerste opzet van deze applicatie heeft nog weinig functionaliteit, hier gaan we verandering in brengen.

Figuur 2 - Standaard Ionic-applicatie zonder menu of tabbladen.

Om de locatie-functionaliteit toe te voegen, moeten we de gewenste Capacitor-plug-in installeren in ons project zodat wij deze kunnen gebruiken. In de documentatie van Ionic voor native functionaliteiten (https://ionicframework.com/docs/native) is een uitgebreide lijst te vinden met alle native API’s die geïnstalleerd kunnen worden en hoe deze te gebruiken. Als eerst voeren we de volgende commando’s uit om de locatie plug-in te installeren.


$ npm install cordova-plugin-geolocation

$ npm install @awesome-cordova-plugins/geolocation

$ ionic cap sync

Vervolgens openen wij het Home-component van onze nieuwe Ionic-applicatie die nu nog de standaard template code bevat waarin wij de locatie gaan gebruiken. Door middel van de volgende code kunnen we eenvoudig de locatie van onze gebruiker opvragen. In de initialisatie van dit component vragen we de huidige positie op via de Geolocation-API en tonen deze in het template.

 

import { Component, OnInit } from '@angular/core';
import { Geolocation, Geoposition } from '@awesome-cordova-plugins/geolocation/ngx';

@Component({
  selector: 'app-home',
  template: `
    <ion-content [fullscreen]="true">
      <div id="container">
        <strong>Uw huidige locatie:</strong>
        <p *ngIf="currentPosition">{{currentPosition.coords.latitude}}, {{currentPosition.coords.longitude}}</p>
        <p *ngIf="!currentPosition">Onbekend</p>
      </div>
    </ion-content>
  `
})
export class HomePage implements OnInit {
  currentPosition: Geoposition;

  constructor(private geolocation: Geolocation) {}

  ngOnInit(): void {
    this.geolocation.getCurrentPosition().then((resp) => {
      this.currentPosition = resp;
    }).catch((error) => {
      console.log('Error getting location', error);
    });
  }

}


Zoals hierboven te zien is, maakt Ionic het ons erg gemakkelijk. Als ontwikkelaar hoef je je helemaal niet bezig te houden met de functionele werking van de locatiebepaling of welke andere native functionaliteit dan ook. We roepen simpelweg de functies aan die de plug-in ons biedt (zoals ‘getCurrentPosition’ in bovenstaand voorbeeld) en Ionic regelt alles achter de schermen voor ons. Er wordt door het besturingssysteem ook automatisch om toestemming gevraagd voor het gebruiken van de locatie.

Figuur 3 - Locatie-toestemming wordt door de telefoon zelf afgehandeld.

Als de locatie succesvol kan worden opgehaald, zien we dat de coördinaten van de locatie in de app worden weergegeven.

Figuur 4 - Locatie-coördinaten worden succesvol opgehaald en weergegeven.

Een volgende stap kan bijvoorbeeld zijn om deze locatie op een kaart weer te geven of op te slaan in een SQL-database op het apparaat. Ionic biedt hier heel veel mogelijkheden in. Het mag duidelijk zijn dat ik als web-ontwikkelaar geen weet heb van de platform-specifieke vereisten voor het toepassen van deze functionaliteiten. Dit is iets wat Capacitor en Ionic ons volledig uit handen nemen.

Conclusie

Ionic biedt een alles-in-één pakket om mobiele-, desktop- en webapplicaties te ontwikkelen die gebruik kunnen maken van systeemeigen functionaliteiten van je toestel. De voordelen die je hieruit kan halen zijn enorm, maar kort samengevat zijn dat:

  • Een naadloze, consistente ervaring voor de eindgebruiker via verschillende kanalen.
  • Eén ontwikkelteam voor zowel mobiele-, desktop- als webapplicaties.
  • Open-source en dus helemaal gratis.
  • Geen kennis nodig van complexe, apparaat-eigen functionaliteiten.

Veel grote tech-bedrijven maken al gebruik van Ionic. Voorbeelden van apps die gemaakt zijn met Ionic zijn Sworkit, MarketWatch en Sanvello. Voor meer voorbeelden verwijs ik je naar de website van Ionic zelf!

Benieuwd naar hoe Ionic binnen jouw organisatie ingezet kan worden? Neem gerust contact op, dan bespreken we samen de mogelijkheden. Ben je zelf een ontwikkelaar met interesse in ontwikkelen van Ionic-applicaties? Kom dan eens langs voor een kop koffie!

Johan Johan / 25-05-2022

4 minuten lezen

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?

Renderen

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.

​Island Architecture

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!

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.

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/

Johan Johan / 04-10-2021

4 minuten lezen

Het Front-End landschap is breed en divers. Er zijn veel technieken, frameworks en methoden om je doel te bereiken. En kies je dan voor grote namen als React, Angular en Vue (de drie grote frameworks van de laatste jaren). Of kijk je ook verder naar nieuwere spelers?

Svelte is zo’n nieuwere speler en begint inmiddels aardig in te lopen, als het gaat om naamsbekendheid en vooral op Developer Experience.

Daarom zoom ik in op Svelte en kijk ik naar de mogelijkheden die dit framework biedt, hoe je het gebruikt en wat SvelteKit precies is.

Het begin

Svelte is gemaakt door Rich Harris, die toentertijd werkte als onderzoekjournalist bij de New York Times. De stukken die hij schreef wilde hij graag kunnen voorzien van interactieve visuals zoals tabellen, grafieken, infographics. Eerst probeerde hij dit te maken met bestaande frameworks, maar dat sloot niet aan bij zijn manier van werken. Dus maakte hij een eigen framework.

Wat maakt Svelte interessant?

Svelte is heel anders in opzet dan bijvoorbeeld React of Angular. Het lijkt eerder op Vue, maar dan nog eenvoudiger. Net zoals bij Vue, maak je gebruik van één bestand voor de styling, de structuur en de logica. Alleen gebruik je bij Vue een .vue bestand, en bij Svelte een .svelte bestand.

Nu is dat niet zo schokkend, maar interessanter is dat Svelte duidelijk andere keuzes maakt dan de drie grote namen. Svelte is zo licht en compact dat het tijdens ontwikkelen een build kan doen in compile-time. Dat betekent dat andere frameworks nog een apart build-proces moeten doorlopen terwijl Svelte direct te gebruiken is. En alles wat niet gebruikt wordt uit het framework, wordt er netjes uitgelaten. Dit wordt tree-shaking genoemd. Andere frameworks doen dit ook, maar Svelte gaat hier zo ver in, dat Svelte code helemaal verdwijnt…

Het unieke van Svelte; het verdwijnt…

Bij veel andere frameworks dient er altijd nog een import te worden gedaan van het framework zelf. In het geval van Svelte is dat niet het geval. De gegeneerde code is alles wat je nodig hebt.

Als we kijken naar het onderstaande codeblock, dan zien we Svelte code waarin een variabele wordt gedefinieerd (genaamd “count”) met een waarde 0. Onderaan zien we de template voor een button, met een on:click handler. Elke keer als er op de button geklikt wordt, wordt “count” verhoogd met 1. Dan zien we iets bijzonders. Op regel 4 staat een $:. Dit betekent dat Svelte dit block aan het watchen is. Dit wordt een Reactive Statement genoemd.

Zodra dit if block true is, is wordt het direct uitgevoerd. In dit geval geeft de browser een waarschuwing, dat “count” nu wel heel hoog wordt.

 

<script>
	let count = 0;

	$: if (count >= 10) {
		alert(`count is dangerously high!`);
		count = 9;
	}

	function handleClick() {
		count += 1;
	}
</script>

<button on:click={handleClick}>
	Clicked {count} {count === 1 ? 'time' : 'times'}
</button>  



Natuurlijk is dit geen 🚀-science, maar vooral het feit dat het zo weinig regels code nodig zijn om dit te bereiken vind ik toch een aardige prestatie. Evenals de Reactive statement: het is geen functie die moet worden afgetrapt; het gebeurt gewoon.

Sveltekit (Svelte + SSR + Routing + nog veel meer)

Naast Svelte als JavaScript framework, is er ook SvelteKit. Dit is meer in lijn met een framework als Nextjs of Nuxt. Oorspronkelijk werd dit in de bèta fase gelanceerd onder de naam Sapper. Sveltekit is nu net uit bèta en biedt Svelte als basis met nog veel meer extra’s zoals Server Side Rendering (SSR) en Routing (de routering van de pagina’s van een website of applicatie). Ook is het mogelijk om Progressive Web Apps te maken met Sveltekit, doordat het slim om kan gaan met caching en ondersteuning voor offline gebruik.

Conclusie; Svelte Zeker de moeite waard

Svelte heeft de laatste jaren een vlucht genomen en is een goede speler geworden binnen het JavaScript landschap. Dit komt ook zeker terug in onderzoeken onder developers. Zo werd het verkozen tot het meest prettige framework om mee te werken in de State of JS 2020 (State of JS 2020: Front-end Frameworks).

Wil jij ook aan de slag met Svelte? Onze Front-End developers gaan hier graag samen met jou mee aan de slag. Neem vooral eens vrijblijvend contact op om de mogelijkheden te bespreken.

Raymon Raymon / 23-06-2021

4 minuten lezen

Het liefst gebruiken we allemaal goed gedocumenteerde UI-componenten in onze Front-End. Met Storybook kan je dit redelijk snel doen met bijvoorbeeld React, Angular, Vue of een ander framework.

Maar je kunt dit ook voor elkaar krijgen zonder een JavaScript-framework, met gewone HTML & CSS! Hier is geen duidelijke documentatie over; daarom werk ik het in deze blog voor je uit.

De installatie van Storybook

Voeg Storybook toe door de volgende opdracht in de terminal uit te voeren.

NPX SB INIT

Met deze opdracht worden alle afhankelijkheden voor Storybook toegevoegd en worden de eerste bestanden gemaakt, zodat je meteen aan de slag kunt.

Na installatie krijg je de vraag “Do you want to manually choose a Storybook project type to install?”. Op deze vraag antwoord je met “yes”.

De tweede vraag die je krijgt is “Please choose a project type from the list”, hierop antwoord je met “HTML”.

Nu zal de CLI alles klaarzetten om Storybook met gewone HTML te gebruiken.

Run npm run storybook wanneer de installatie is voltooid.

Algemene instellingen

Wanneer je je directory bekijkt, zie je een map .storybook. In deze map bevinden zich twee bestanden, main.js en preview.js .

In het bestand main.js kan je instellen in welke map wordt gecontroleerd op *.stories.js-bestanden (andere bestandsextensies zijn mogelijk). Storybook heeft ook een plug-insysteem genaamd addons die je hier ook kunt toevoegen.

In het preview.js-bestand kan je alles toevoegen dat moet worden geladen wanneer je een voorbeeld van je UI-componenten bekijkt. Voeg bijvoorbeeld je globale CSS-bestand of pictogramlettertype toe om het beschikbaar te hebben in alle component.

Voorbeeld storyfile voor gewone HTML

In de map stories vind je het bestand Button.stories.js. Het ziet er zo uit:

 
import { createButton } from './Button';

export default {
  title: 'Example/Button',
  argTypes: {
    label: { control: 'text' },
    primary: { control: 'boolean' },
    backgroundColor: { control: 'color' },
    size: {
      control: { type: 'select', options: ['small', 'medium', 'large'] },
    },
    onClick: { action: 'onClick' },
  },
};

const Template = ({ label, ...args }) => {
  // You can either use a function to create DOM elements or use a plain html string!
  // return `<div>${label}</div>`;
  return createButton({ label, ...args });
};

export const Primary = Template.bind({});
Primary.args = {
  primary: true,
  label: 'Button',
};

export const Secondary = Template.bind({});
Secondary.args = {
  label: 'Button',
};

export const Large = Template.bind({});
Large.args = {
  size: 'large',
  label: 'Button',
};

export const Small = Template.bind({});
Small.args = {
  size: 'small',
  label: 'Button',
};

Dit is een uitstekend voorbeeld van hoe een story file eruitziet. De code in Button.js maakt een < button>-element aan.

 
import './button.css';

export const createButton = ({
  primary = false,
  size = 'medium',
  backgroundColor,
  label,
  onClick,
}) => {
  const btn = document.createElement('button');
  btn.type = 'button';
  btn.innerText = label;
  btn.addEventListener('click', onClick);

  const mode = primary ? 'storybook-button--primary' : 'storybook-button--secondary';
  btn.className = ['storybook-button', `storybook-button--${size}`, mode].join(' ');

  btn.style.backgroundColor = backgroundColor;

  return btn;
};

Ook al ziet het er goed en duidelijk uit, de manier waarop de createButton een < button>-tag maakt, laat ons geen duidelijk codevoorbeeld genereren om te kopiëren en te plakken. Dus we gaan het een beetje anders doen.

Eenvoudige HTML-story met codevoorbeeld

Om dit te laten werken, hebben we een Storybook-add-on nodig. Voer de onderstaande code uit om het te installeren.

npm i @ storybook/addon-storysource

Voeg het na installatie toe aan het .storybook/main.js-bestand zoals hieronder.

 
module.exports = {
  "stories": [
    "../stories/**/*.stories.mdx",
    "../stories/**/*.stories.@(js|jsx|ts|tsx)"
  ],
  "addons": [
    "@storybook/addon-links",
    "@storybook/addon-essentials",
    "@storybook/addon-storysource"
  ]
}

Maak vervolgens een map helpers in de verhalenmap. Maak in die map een bestand “code-example.js”. In dit bestand zullen we een helperfunctie maken die gegevens genereert voor ons codevoorbeeld.

 
function addCodeExample(component, templateConfig) {
  if(!component || !templateConfig) return

  component.parameters = {
    docs: {
      source: {
        code: templateConfig({
          label: component?.args?.label,
          className: component?.args?.className
        })
      }
    }
  }

  return component
}

export { addCodeExample }

In deze functie nemen we de component en de templateConfig als parameters. Deze parameters geven ons informatie van de componenten zelf.

Voor dit voorbeeld zal ik de lengte van de Button.stories.js minimaliseren door slechts één voorbeeld van een knop toe te voegen. Dus kopieer en plak de onderstaande code.

 
export default {
  title: 'Example/Button',
  argTypes: {
    label: { control: 'text' },
    className: { control: 'text' }
  },
};

const Template = ({ label, className }) => {
  return `<button class="${className}">${label}</button>`;
};

export const Primary = Template.bind({});
Primary.args = {
  label: 'Button',
  className: 'button-primary',
};

Wanneer je de button-component bekijkt in Storybook, is jouw codevoorbeeld nog niet klaar om te knippen en te plakken.

Button-component in Storybook

Door de functie te gebruiken om dat voorbeeld te genereren, zie je het verschil.

 
import { addCodeExample } from './helpers/code-example'

export default {
  title: 'Example/Button',
  argTypes: {
    label: { control: 'text' },
    className: { control: 'text' }
  },
};

const Template = ({ label, className }) => {
  return `<button class="${className}">${label}</button>`;
};

export const Primary = Template.bind({});
Primary.args = {
  label: 'Button',
  className: 'button-primary',
};
addCodeExample(Primary, Template)


Hier kan je zien dat ik Primary als de eerste parameter en Template aan de volgende heb toegevoegd. Dit genereert de eenvoudige HTML-code die je kunt kopiëren en plakken.

Conclusie

Nu je weet hoe je Storybook met gewone HTML en CSS moet gebruiken, kan je jouw UI-component veel beter maken!

Storybook is een geweldig hulpmiddel om in elke webtoepassing te gebruiken! Ik ben er super blij mee! Als je hun project op Github wilt bekijken en wat waardering wilt tonen, bekijk ze dan hier: https://github.com/storybookjs/storybook

Ben je ook van plan om Storybook te gebruiken met HTML? Laat het me weten!

{description}

Heb je een Microsoft Expert nodig?

Neem contact met ons op
{description}

Zoek je een nieuwe baan?

Bekijk onze vacatures