React Async package

Spreker: Gert Hengeveld

Door: Mitchell Izelaar

De meeste ontwikkelaars gebruiken packages van andere ontwikkelaars. Het is ontzettend handig dat je code van een ander kan gebruiken, dit scheelt veel tijd en is vaak makkelijk om te doen. Alleen sta je er vaak niet bij stil dat de andere ontwikkelaar veel tijd steekt in zijn package. Gert Hengeveld legt in zijn talk globaal uit wat er bij komt kijken om een package te maken, en waar hij tegen aan liep bij het maken van zijn React Async package.

Tijdens het maken van de package moet je al rekening houden met veel diverse scenarios waar je zelf misschien niet aan gedacht had. Zo moest Gert ook rekening houden met diverse smaken van React, denk aan React Native bijvoorbeeld. Daarnaast staat React ook niet stil, dus elke keer als er een nieuwe versie van React komt moet hij ervoor zorgen dat zijn package gewoon werkt. Gert vond het zelf ook erg belangrijk dat zijn package backwards compatible is.

Om ervoor te zorgen dat het testen, bij voorbeeld een nieuwe versie van React, niet al te veel tijd kost is zijn package 100% getest. Hiervoor gebruikt hij Jest. 100% code coverage heeft nog meer voordelen namelijk dat als andere ontwikkelaars een pull request maken voor React Async dat hij direct kan zien of de tests nog werken. Is dat niet het geval dan hoeft hij niet eens naar de pull request te kijken, wat veel tijd scheelt. Daarnaast geeft 100% code coverage ook meer geloofwaardigheid. Bij Github zie je namelijk badges staan met onder andere de de code coverage, grootte, licence etc. Dit valt erg op en wordt door veel ontwikkelaar meegenomen in de keus of ze de package kan gebruiken. Uiteindelijk is het natuurlijk het doel dat ontwikkelaars jou package gaan gebruiken. Wat daarin ook bijdraagt is goede documentatie. Daarom heeft Gert een uitgebreide documentatie geschreven inclusief veel examples.

Het was interessant om te zien hoeveel tijd en moeite erin gaat zitten om een package te maken en te onderhouden. Dus in plaats van het voor lief nemen dat er zoveel packages zijn is het misschien eens leuk om zelf bij te dragen aan een package of er zelf een te maken!

The state of Web Components (with a bit of React)

Spreker: Pieter van Drost

Door: Tijmen van den Bos

Pieter van Dorst was de tweede spreker van de avond met zijn presentatie “The state of Web Components (with a bit of React)”. Hij is een Full stack JavaScript developer werkende bij Passionate People en heeft onder andere gewerkt aan de Web Components library van ING. In zijn talk begint Pieter met een korte geschiedenisles om ons zo mee te nemen naar de huidige staat en de toekomst van Web Components.

Voor iedereen die denkt “Wat zijn Web Components eigenlijk?” heeft de MDN web docs een mooi stukje uitleg geschreven.

“Web components are a set of web platform APIs that allow you to create new custom, reusable, encapsulated HTML tags to use in web pages and web apps. Custom components and widgets build on the Web Component standards, will work across modern browsers, and can be used with any JavaScript library or framework that works with HTML.”[1]

Als dat wat abstract is kan je het ook zien als een soort docker container voor html, css en JavaScript code die in de browser draait. Web components zijn bedoelt om het onderhouden en hergebruiken van de elementen waaruit website opgebouwd zijn gemakkelijker te maken. Het mooiste aan Web Components is dat bijna alle moderne browsers ze out of the box ondersteunen.

Nu we een beeld hebben van wat Web Components zijn, kunnen we een kijken naar hoe ze zijn ontstaan. Hiervoor moeten we terug naar 2011, de tijd dat Angular JS nog maar een jaar bestond en de meeste website geschreven waren in een combinatie van html, css en misschien wat JavaScript. Deze combinatie was prima voor statische content, maar leverde een hoop ongewenste complexiteit op voor de meer dynamische website. In deze periode kwam Alex Russell met een aantal nieuwe ideeën over de toekomst van het web, welke hij op de Frontiers Conference 2011 presenteerde in de talk “Web Components and Model Driven Views”[2]. Hij besprak hierin de basis van wat nu de Web Component standaard is.

Het duurde tot 2013 voor de release van Polymer, een web component library van Google. Deze library gaf ons de mogelijkheid om zelf met Web Components aan de slag te gaan. Maar net zoals veel nieuwe technieken was Polymer niet perfect. Zo hadden browsers nog geen ingebouwde ondersteuning voor Web Components en konden test tools slecht omgaan met de shadow DOM. De shadow DOM is een ingekapselde DOM in de normale DOM welke intergraal onderdeel is van de web component standaard.

Sinds de release van Polymer is er een hoop veranderd. Zo heeft Firefox, in oktober 2018, als eerste browser ondersteuning voor web componenten toegevoegd wat libraries zoals Polymer overbodig maakt. De meeste grote browsers hebben het voorbeeld van Firefox opgevolgd door ook ondersteuning toe te voegen. De enige uitzondering hierop is Microsoft Edge waar ze op het moment van schrijven hard aan het werken zijn om over te stappen naar Chromium.

Hoe werken Web Components?

Met deze korte geschiedenisles kunnen we eindelijk beginnen met een korte programmeer oefening. Hiervoor gaan we een bestaande open source web component toevoegen aan een website waar je momenteel aan werkt.

Als eerste kiezen we uit een van de vele open source libraries op open-wc.org[3] een mooi component kiezen. Voor deze oefening gebruik ik het amp.dev youtube component[4]. Hierna moeten we de browser laten weten waar de source van het web component dat we willen tonen staat. Voeg hiervoor de volgende twee regels code toe aan de header van je website.

<script async src="https://cdn.ampproject.org/v0.js"></script> <script async custom-element="amp-youtube" src=“https://cdn.ampproject.org/v0/amp-youtube-0.1.js"></script>

Voeg hierna de volgende regel toe aan de body, herlaad de pagina en je kan genieten van een prachtige YouTube video.

<amp-youtube width="480" height="270" layout="responsive" data-videoid=“dQw4w9WgXcQ"></amp-youtube>

Hoe maak ik zelf een Web Component?

Nu je zelf een Web Component heb toegevoegd zit je vast en zeker te popelen om er een te maken. Helaas moet ik, om deze blog bondig te houden, je hiervoor doorsturen naar de Mozilla tutorials pagina[5] waar ze het veel beter uitleggen dan ik hier ooit zou kunnen doen. Wat ik wel kan bespreken zijn de vier specificaties die nodig zijn om een Web Component ta maken, namelijk:

1. Custom Elements Custom elements zijn bijna hetzelfde als de bekende html elementen, zoals “table” of “div”. Het grote verschil is dat je ze volledig kan aanpassen met een unieke naam en een berg aan functionaliteiten. Om ervoor te zorgen dat je browser jou element herkent moet elk Web Component de volgende regel code bevatten.

customElements.define(name, element)

De “name” is de naam van de element selector, b.v. ‘awesome-table’, en het element is de ES class, met alle functionaliteit en de HTML template, die je wil blootstellen.

2. HTML Template De HTML template wordt samen met alle andere code blootgesteld via de ES class door middel van de “customElements.define()” code. In tegenstelling tot hoe HTML normaal gerenderd wordt, namelijk direct, rendered de HTML code van een Web Component pas wanneer wij dat willen. Dit geeft ons veel meer controle over wanneer we iets willen weergeven of verbergen.

3. Shadow DOM De shadow DOM is al eerder te sprake gekomen, maar het kan geen kwaad om de beschrijving nog een keer te herhalen. De shadow DOM is net zoals de normale DOM maar dan volledig ingekapseld. Dit zorgt ervoor dat de code in de Web Component zit geen effect heeft op de rest van de website, en dus ook geen onverwachte bijwerkingen heeft.

4. ES modules ES modules zijn technisch gezien geen onderdeel van de Web Components zelf, maar wel verdomt handig om ze toe te voegen aan je website. Kijk maar naar het YouTube voorbeeld.

Waar kruizen Web Components en frameworks elkaar? De volgende vraag die je kan hebben is “Waarom zou ik Web Components gebruiken als Angular, Vue of React het zelfde kan doen?”. Dit is wat het team achter React erover te zeggen heeft.

“React and Web Components are built to solve different problems. Web Components provide strong encapsulation for reusable components, while React provides a declarative library that keeps the DOM in sync with your data. The two goals are complementary. As a developer, you are free to use React in your Web Components, or to use Web Components in React, or both.”[6]

Deze quote stipt twee interessante punten aan over het combineren van Web Componenten en frameworks. Namelijk dat ze allebei andere problemen oplossen en dat er meerdere manieren zijn om ze te combineren.

Laten we eerst kijken naar de verschillende problemen die Web Components en frameworks oplossen. Terugkijkend naar wat we tot nu toe geleerd hebben is het redelijk duidelijk waarom we Web Components willen gebruiken, namelijk de verschillende browsers ze out of the box ondersteunen en het heel gemakkelijk is om ze te hergebruiken.

De vraag is dus meer waarom we ze willen gebruiken in plaats van de oplossingen die frameworks zoals Angular, React en Vue bieden? De voornaamste reden hiervoor is dat de verschillende frameworks de Web Components imiteren en je dus niet de voordelen ervan heb. Je bent dus nog steeds afhankelijk van de framework specifieke code om het component te laten werken. En hoe je het ook went of keert, frameworks komen en gaan terwijl de onderliggende technieken, zoals JavaScript, nog steeds gebruikt worden.

Helaas werken nog niet alle frameworks lekker samen met Web Components. Dit is wat Pieter erover te zeggen had.

“We aren’t there yet […], it’s pretty much the end goal we are striving to.”[7]

Waarschijnlijk gaan we in de komende jaren een verschuiving zien in het front-end landschap waar we langzaam overstappen naar het gebruik van Web Components in plaats van de framework specifieke componenten. Tot die tijd moeten we ze zelfs maar moeten combineren.

Het tweede gedeelte van de quote gaat over de verschillende manieren waarop we Web Components kunnen combineren met frameworks. Bij het gebruik van Web Components in een framework kan je vast wel iets bedenken. Let er wel op dat er haken en ogen aan het gebruik van Web Components in frameworks kunnen zitten. Zo is de data binding in React zo opgezet dat het alles als String objecten overzet. Hierdoor moeten complexe datastructuren handmatig geparset worden, wat de Web Components een stuk complexer maakt. Controleer voor je begint met het toevoegen van Web Componenten aan een framework eerst of ze goed samen werken op https://custom-elements-everywhere.com/.

Naast Web Components in een framework gebruiken kan je het ook omdraaien en een framework in een Web Component gebruiken. Pas wel op dat je niet teveel verschillende frameworks, of versies van frameworks, tegelijkertijd gaat gebruiken. Alle verschillende versies moeten namelijk als dependency opgenomen worden wat een hoop extra complexiteit met zich meebrengt. Iets wat we juist proberen op te lossen met het gebruik van Web Components.

Samenvatting Om deze blog af te sluiten heb ik nog een mooie opsomming van wat we geleerd hebben. Het belangrijkste om te herinneren is dat je met Web Components zonder dependencies herbruikbare en onderhoudsarme componenten voor je website kan maken. Hou er rekening mee dat het geen wondermiddel is dat al onze problemen oplost, maar het help wel om een beter front-end ecosysteem te creëren. Als allerlaatste nog kort de voor en nadelen van Web Components.

Pro’s: - Geen dependencies nodig door de ingebouwde ondersteuning in browsers. - Herbruikbaarheid van Web Componenten verminderd de vendor lock in. - Toegang tot een groeiende bibliotheek aan bestaande Web Components. - Web Componenten zijn ontworpen om super snel te zijn.

Con’s: - Testen is nog steeds moeilijk door de shadow DOM. - Het combineren van Web Components en frameworks kan lijden tot extra overhead en complexiteit als je niet oppast. - Ondersteuning voor oude browsers is niet geweldig, ook niet met polyfills.

1. MDN web docs, Web Component documentation, https://developer.mozilla.org/en-US/docs/Web/Web_Components
2. Web Components and Model Driven Views by Alex Russell, (2011), https://fronteers.nl/congres/2011/sessions/web-components-and-model-driven-views-alex-russell
3. List of open source web component libraries, https://open-wc.org/faq/component-libraries.html
4. Amp.dev youtube web component, https://amp.dev/documentation/components/amp-youtube?format=websites
5. Mozilla web components documentation, https://developer.mozilla.org/en-US/docs/Web/Web_Components#Tutorials
6. Statement from React about web components, https://reactjs.org/docs/web-components.html
7. Quote Pieter van Dorst about React and web components, (2019), https://youtu.be/MIaKV-zM1Lg?t=5944