Nel precedente articolo sui Web Component si è fatta luce sugli aspetti tecnici e di sviluppo evidenziando una serie di problematiche emerse da questa disamina preliminare. In questa terza, e ultima parte, scendiamo nel dettaglio comprendendo come poter risolvere questi problemi.
Logiche interne
L’idea di poter creare nuove tipologie di input utente è tra le prime che sono emerse durante la stesura delle specifiche dei Web Component. E, al momento attuale (gennaio 2022), il problema è risolto ma solo nei browser basati su Chromium (Chrome, Edge, Opera, Brave…).
La soluzione si basa sull’introduzione di un oggetto della classe ElementInternals, associato ad un Custom Element tramite l’uso del metodo attachInternals:
class RadioGroupElement extends HTMLElement {
#internals;
constructor() {
super();
this.#internals = this.attachInternals();
...
}
}
customElements.define('radio-group', RadioGroupElement);
Si noti come il valore di ritorno della funzione sia stato messo su un campo privato: questo non è un requisito, ma è ragionevole dal momento che l’oggetto in questione definisce delle meccaniche interne e quindi normalmente non esposte ad intervento esterno.
La classe ElementInternals mette a disposizione una serie di metodi e di proprietà che consentono al nostro elemento custom di definire il suo comportamento all’interno di un elemento <form>, al pari dei vari <input>, <select>, ecc…
In particolare, consente di impostare i seguenti valori:
- il valore che il Custom Element assume all’interno del form – al pari della proprietà `value` dei controlli di form classici;
- il suo stato di validità, vale a dire il rispetto dei vincoli di validazione impostati sull’elemento (es.: lunghezza minima, formattazione, valore massimo, …).
Aggiungendo la proprietà statica di classe formAssociated impostata a true il browser sarà in grado di trattare il nostro componente al pari degli elementi classici di input, e di includere il suo valore all’interno del payload inviato.
L’ostacolo principale a tutto ciò è il fatto che il supporto a ElementInternals è disponibile su Chromium e sui browser derivati, e a breve anche su Firefox, mentre per WebKit (Safari) è ancora allo stato embrionale. Fortunatamente, però, la situazione in merito si è recentemente sbloccata rispetto a qualche settimana fa, ed è plausibile che il supporto completo arrivi entro il 2022.
Per il resto, se già l’applicazione gestisce i form tramite vie non native con JavaScript (come è solito fare in diversi framework), questo problema è di secondaria importanza.
Accessibilità
Gli elementi nativi hanno tutti una loro connotazione semantica, stabilita dagli standard di accessibilità delle Web Content Accessibility Guidelines (WCAG), affinché il web sia navigabile dalle tecnologie assistive in maniera chiara e standardizzata. In questo modo, ogni <h1> è dichiarato come un’intestazione, <table> come contenuto tabellare e via dicendo. Ma cosa accade con i nostri elementi “custom”?
Ogni Custom Element che abbia uno Shadow DOM dichiarato come “aperto” (come da prassi comune) è esplorabile dalle tecnologie assistive e comunicato al loro utilizzatore in maniera non dissimile a quanto avviene nel DOM classico. La vera differenza viene data dal valore semantico dell’elemento “host” stesso, che è inizialmente nullo.
Questo non è un problema nuovo, si badi. Anche usando i vari framework di front-end e quindi senza ricorrere a Custom Element ma solo agli elementi nativi del browser, ci si deve occupare di dare una semantica ai propri componenti. Questo viene fatto tramite gli attributi role e aria-* definiti sull’elemento.
Per i Custom Element si può fare altrettanto. Per evitare che questi valori possano essere manomessi dall’esterno si possono usare le proprietà con lo stesso nome definite sull’oggetto ElementInternals definito poco sopra, con in più altre potenzialità. Anche questo è disponibile sui browser basati su Chromium (nemmeno su Firefox), e al momento in sviluppo sugli altri.
Server-Side Rendering (SSR)
Come è emerso da quanto visto, i Web Component si basano in maniera consistente sull’uso di API del browser. Questo può essere un problema qualora si volesse usare il Server-Side Rendering per le generazione sul back-end delle pagine esposte. In sostanza, la creazione di HTML contenente elementi custom comporta l’assenza del loro shadow DOM e significato semantico.
I motivi per adottare SSR sono dei più svariati; tra essi:
- facilitare l’esplorazione robotizzata ai fini di Search Engine Optimization (SEO) e condivisione dei contenuti;
- abbreviare i tempi di First Contentful Paint e così rendere le pagine fruibili più velocemente;
- alleggerire il carico di lavoro iniziale dei client al momento della ricezione dei contenuti.
Ma, come già accennato nel primo articolo di questa serie, il Declarative Shadow DOM è una feature che risolve i problemi menzionati.
D’altra parte, tale tecnologia è presente, ancora una volta, sui browser basati su Chromium e pertanto c’è necessità di polyfill per gli altri.
All’atto pratico, usare il Declarative Shadow DOM consiste nell’inserire un tag <template> con attributo shadowroot all’interno del nostro elemento custom, e questi riceverà in automatico uno Shadow DOM già costruito:
<my-card cardtitle="Titolo della card">
<template shadowroot="open">
<header>
<h4>Titolo della card</h2>
<button type="button">⌄</button>
</header>
<div><slot></slot></div>
</template>
<p>Contenuto della card</p>
</my-card>
class CardElement extends HTMLElement {
constructor() {
super();
// Controllo che lo Shadow DOM non sia stato già creato
// tramite Declarative Shadow DOM
if (!this.shadowRoot) {
this.attachShadow({ mode: 'open' });
...
}
}
}
customElements.define('my-card', CardElement);
A che pro?
Ci sono molti altri dettagli che i Web Component devono risolvere, ma che sostanzialmente non ne impediscono il loro uso diffuso. Ma, a questo punto, ci si deve chiedere quale sia il reale caso d’uso dei Web Component.
Abbiamo accennato al fatto che uno dei principali obiettivi dell’idea dei Web Component fosse quella di avere un sistema standard di creazione di componenti, in modo che si potessero usare con qualsiasi altra tecnologia web. In questo senso, l’utilizzo principe dei Web Component è quello di essere usati per librerie di componenti che assolvono uno scopo minimale, ben circoscritto e sufficientemente generico.
E, d’altronde, è anche l’uso che è stato fatto in maniera più diffuso dei Web Components: qui è possibile vedere un elenco selezionato di tali librerie, scelte tra solo quelle open source.
Per spingere oltre il loro utilizzo, è possibile prevedere un uso anche sotto forma di widget riutilizzabili e auto-contenuti. Per il resto, anche se tecnicamente è possibile creare intere applicazioni come Web Component, è sicuramente una sfida in più in quanto non sono previste – almeno non a breve – soluzioni per problemi quali gestione dello stato, controllo della navigazione e via dicendo.
Questi problemi sono già stati affrontati dai vari framework come Angular, React e via dicendo, e con i quali è possibile lavorare con i Web Component.
Come procedere?
Sviluppare Web Component da zero può essere complesso, in quanto le API a disposizione sono piuttosto a basso livello e costringono ad un lavoro piuttosto verboso e poco mantenibile.
Per questo, sono nate diverse librerie per lo sviluppo di Web Component che ne facilitano lo sviluppo, consentendo un’interfaccia più dichiarativa e lasciando le logiche specifiche a carico del programmatore.
A riprova del fatto che i Web Component hanno già raggiunto uno stato di maturità sufficiente alla produzione di siti e applicazioni web, è bene notare come il trend di adozione sia in costante crescita negli ultimi mesi:
È quindi normale che in Antreem abbiamo avuto a che fare già diverse volte con la tecnologia, sempre più notata, richiesta e proposta in ambito business, e adottata anche come utile strumento interno di condivisione.
Ci preoccuperemo di aggiornarvi con le novità in merito ai Web Component su questo stesso blog nei mesi a venire.
Ti sei perso gli articoli precedenti? Li trovi qui sotto.
