Benvenuti su GITBAR, il podcast dedicato al mondo dei full stack developer, i mezzo artigiani, i mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.Benvenuti in un nuovo episodio di GITBAR, questa volta pienamente estivo, anche se con un setup un po' di fortuna visto che il mio Mac è praticamente imploso viste le temperature si è praticamente surriscaldato talmente tanto da somigliare a una stufa allogena piuttosto che a un computer e la mia dimenticanza del microfono.In fondo quindi la cosa più importante è che riusciamo anche questo giovedì a pubblicare un episodio.Questo giovedì voglio parlarvi di Web Components.voglio farlo anche perché questo tipo di puntata è propedeutica alla puntata che andrò a registrare domani e che nella quale cercheremo di affrontare con un ospite speciale il mondo dei micro front-end però prima di parlare di micro front-end è necessario infatti iniziare a dare uno sguardo al mondo dei web components sulla rete esiste tantissimo materiale, anche un talk del mio amico Francesco Sciuti, talk del quale vi inserirò nelle note dell'episodio il link.Noi andremo a vederlo un po' giusto per inquadrarne il contesto.Essendo un podcast audio è veramente difficile poter spiegarne i dettagli implementativi e come utilizzarlo visto che non vi posso far vedere del codice.però proveremo comunque a introdurre l'argomento.Lo faremo subito dopo avervi ricordato i contatti.Potete scrivermi a info@gitbar.it oppure su Twitter @brainrepo.Mi state già scrivendo in tanti tanto che pensavo, ne stavo ragionando sul fatto di creare un gruppo Telegram.Quasi sicuramente lo andremo a creare a settembre quindi alla fine di questa di questo periodo estivo e in questo gruppo ci scambieremo un po di idee e mi darete anche una mano a scegliere gli argomenti per gli episodi detto questo possiamo iniziare uno dei motivi per cui usiamo i framework javascript è senza dubbio perché ci mettono a disposizione la possibilità di di dividere e di organizzare la nostra applicazione in componenti.Per cui se questo è l'elemento trainante verso l'utilizzo di un framework, una domanda sorge spontanea.Ma dobbiamo portarci appresso tutta la complessità che ci viene da un framework solo perché vogliamo utilizzare un approccio a componenti? Beh, la risposta è no.Il vantaggio di poter lavorare con la tecnica del "Divide e Timpera" quindi frammentare il nostro codice in elementi incapsulati, a sé stanti è un vantaggio molto importante.Vantaggio che tra l'altro è stato colto dal V3C che già nel 2011 ha fatto la prima draft per la realizzazione di API standard volte proprio alla creazione del concetto dei web components.Quindi con questo passaggio si è avuto all'interno dell'API standard di javascript nel browser la possibilità di creare degli elementi personalizzati, degli elementi HTML personalizzati, ma in modo nativo.Questo rende da una parte la possibilità di sviluppare dei componenti che sono poi alla base del modo moderno di scrivere le applicazioni web anche perché oggi voi col paradigma NVVM voi con un approccio più interattivo, più reattivo nello scrivere nell'interfaccia si ha la necessità di avere dei componenti non solo definiti dal punto di vista strutturale ma che operano e hanno dei comportamenti, comportamenti definiti però in questo caso all'interno dello stesso componente.Questo fa sì che la nostra logica sia più ordinata e che tutto sia in qualche modo ragionato sotto forma di elementi atomici.Questo è molto molto molto interessante anche perché se abbiamo bisogno oggi di sviluppare un'applicazione quindi di utilizzare dei web components possiamo tranquillamente farlo senza portarci appresso appunto le responsabilità che che si hanno utilizzando dei framework come può essere React o Angular per cui facendolo semplicemente in vanilla JavaScript I Web Components critical API standard sostituiranno i framework? Secondo me no perché i vantaggi che i framework inseriscono e portano a questo mondo sono anche altri Per esempio i framework hanno dei sistemi per la gestione dello stato che sono molto molto efficaci e anche molto pratici da utilizzare.I framework hanno per esempio delle ottime librerie di routing.Quindi in realtà per ora possiamo immaginare che i due elementi convivano insieme.E da questa convivenza ne abbiamo una serie di vantaggi.Immaginate di lavorare in un grosso team per un prodotto di una certa dimensione.Possiamo pensare a un Netflix della situazione.All'interno dell'azienda e del prodotto esistono una serie di team che lavorano sul prodotto.Ogni team utilizza magari una tecnologia o un framework ad hoc.che ne so, la parte di autenticazione utente risale a qualche anno fa ed è stata sviluppata con AngularJS la parte di catalogo è stata sviluppata con React se io volessi creare un design system, cioè una raccolta di regole per la realizzazione estetica e di UX degli elementi che vanno a costruire la pagina e condividerlo con tutti i team avrei un problema.Perché? Perché il team di Angular ha scritto i componenti con quella libreria.Il team che ha lavorato su React o su Vue hanno utilizzato il loro framework per scrivere i componenti.A questo punto entrano in gioco il concetto di web components nativi, quindi sviluppati utilizzando l'API dei custom elements, lo shadow DOM e magari anche i template.Quindi questi elementi scritti con le API native riescono in qualche modo a fare da ponte per tutti questi framework.Per cui in un progetto di medie e grosse dimensioni si ha la possibilità di condividerli.In questo modo il codice è riutilizzabile.È riutilizzabile anche in modo molto più spinto e soprattutto questi componenti sono in qualche modo universali all'interno del contesto della nostra applicazione.Questo tipo di component scritti con le API native, per esempio, li troviamo all'interno delle AMP, le pagine mobile, quelle che vengono indicizzate da google in un modo particolare, vengono lette da facebook in un modo altrettanto particolare, non sono altro che un file javascript che definisce una serie di componenti che poi tu utilizzi all'interno della stessa pagina.Scrivere questi web components, come vi dicevo prima, vuol dire mettere mano a tre concetti principali.Il primo sono i custom elements, quindi la definizione di tag HTML custom utilizzando un API JavaScript definita.La seconda è lo Shadow DOM.Perché? Perché i web components hanno una particolare caratteristica che è quella dell'essere incapsulati.Per cui ci serve uno strumento per andare a scrivere del codice HTML che rimane incapsulato in una sorta di scatoletta e che non va a interferire con gli altri elementi e i componenti che lo circondano e quindi le API JavaScript ci mettono a disposizione anche questo tipo di strumento e per finire i templates perché il modo per creare gli elementi custom è quello di andare poi a interagire col DOM sappiamo quanto può essere doloroso lavorare col DOM in JavaScript, utilizzare appunto l'API per andare a scrivere e modificare il DOM con JavaScript.Per ovviare a questo problema abbiamo uno strumento, si chiamano HTML templates, sono dei tag dove noi all'interno definiamo una struttura HTML che poi possiamo utilizzare in un secondo momento tramite JavaScript, esempio clonandola e andando a interpolare dei valori.Questa struttura però quando io me la vado a creare, me la vado a definire in modo con del codice HTML non viene mostrata all'interno della pagina e quindi mi evita in qualche modo il dover scrivere le azioni sul DOM, quindi definire gli elementi del DOM in modo programmatico che, come vi dicevo, è molto impegnativo.Per cui l'utilizzo di questi tre elementi ci danno la possibilità di creare dei Web Components.Web Components che possiamo creare utilizzando il primo elemento, quello dei Custom Elements.dal mio punto di vista condizione sine qua non per realizzare un Web Components Custom Elements non sono altro che una classe che estende la classe HTML Element è una classe ECMAScript 6 quindi vuol dire che deve essere per forza definita con la parola chiave class e non possiamo trasformarla magari usando webpack se non attraverso l'uso di particolari plugin perché appunto uno dei requisiti è quello che debba essere una classe ECMAScript 6 o ECMAScript 15 chiamatelo come volete che estende come vi dicevo HTML element.Il fatto che estenda quest'altra classe che si chiama HTML element gli permette di ereditare praticamente tutta la DOM API quindi tutte le funzionalità che permettono di interagire col DOM e tra l'altro una cosa molto interessante è che attraverso il DIS all'interno della classe noi andiamo a interagire con il DOM del componente quindi interno al componente.Iniziamo quindi qua a percepire un certo incapsulamento.Questi componenti come ci sarà capitato anche vedendo insomma il codice react o angular o view hanno un ciclo di vita che inizia con la creazione quindi il momento in cui noi andiamo a definire il nostro custom element.Questa definizione viene fatta semplicemente chiamando dalla variabile globale custom elements il metodo define che prende in ingresso il nome del tag che vogliamo creare e questa famosa classe che ne implementa la logica.Da questo momento in poi noi possiamo utilizzare all'interno della nostra pagina HTML questo tag nuovo con i comportamenti che ne abbiamo definito.Comportamenti definiti appunto all'interno del corpo della nostra classe.Abbiamo anche due metodi che sono delle callback e ci permettono di attaccarci nel momento in cui il componente viene montato nel DOM e nel momento in cui viene disconnesso, smontato.Avere questi ascoltatori, queste callback, ci permettono quindi di, per esempio, quando viene montato scaricare delle risorse remote oppure fare il rendering e invece quando viene montato una cosa interessante che posse...quando viene smontato una cosa interessante che possiamo fare è quello di per esempio chiudere le connessioni ad index e db se lo usiamo oppure direttamente ammazzare degli event eventuali event listener che abbiamo creato Un'altra cosa interessante è l'attributeChangedCallback che è un terzo, un quarto metodo, perché c'è anche il costruttore, però è un ulteriore metodo che ci permette di osservare quando gli attributi, quindi i valori che noi mettiamo all'interno del nostro custom element, cambiano e quindi di reagire al comportamento.Non tutti gli attributi vengono ascoltati di default, ma ne definiamo l'ascolto attraverso l'uso di un altro metodo che ci permette appunto di definire quelli che sono gli attributi osservati.Quindi con questo tipo di elementi noi abbiamo la possibilità di creare a questo punto dei componenti che hanno una loro logica all'interno.Farlo è un pochino macchinoso quindi oltre ai custom element abbiamo bisogno di un'altra serie di strumenti per esempio uno che ci permetta un un incapsulamento ancora più forte strumento che si chiama Shadow DOM che cos'è lo Shadow DOM? a me piace immaginare lo Shadow DOM come un modo per contenere lo sporco se per sporco intendiamo forzando un po' il concetto il codice HTML e CSS che è sempre un po' disordinato direi anche palloso da definire utilizzando appunto le Dome API con JavaScript.Quindi esiste un modo per incapsulare il tutto all'interno di una scatoletta che non interferisce con gli elementi all'esterno.Io mi incapsulo il mio codice HTML, il mio CSS, ho la possibilità per esempio di incapsulare anche degli eventi.Per darvi un'idea di che cosa sia lo Shadow DOM mi viene da indicarvi il video player, il componente video player di HTML, quindi un componente nativo.E se voi andate su Chrome esiste la possibilità di andare a spezionare lo Shadow DOM, magari vi metto due righe nelle note dell'episodio se riesco.Se voi attivate quella funzione avrete la possibilità di andare a esplorare sulla struttura degli elementi grafici di quel player.Per esempio potrete andare a vedere il play button come è costruito, piuttosto che il pause, piuttosto che la progress bar.Ed è molto interessante perché quando noi lo vediamo dall'esterno, noi percepiamo un unico componente, un unico elemento, che è appunto il nostro video player HTML.ma all'interno c'è una molteplicità di elementi che vengono orchestrati e che agiscono in modo coordinato e in modo nascosto.Quindi tutto quel tipo di complessità viene appunto mimetizzata, non viene mostrata.Il terzo elemento, terzo ed ultimo elemento che ci viene in aiuto quando andiamo a definire il nostro web components utilizzando il custom element e lo shadow DOM sono i template come vi dicevo è veramente palloso dove andare a interagire col DOM e andare a creare dei divi in modo programmatico per evitare questo esiste un tag si chiama il tag template che permette di inserire al suo interno del codice html scritto in modo dichiarativo quindi esattamente come se state scrivendo un classico file HTML.Però il contenuto di questo tag template non viene mostrato nella pagina.Quindi non appare.Tra l'altro potete inserirci degli stili.Potete per esempio inserire degli script che non vengono eseguiti all'esecuzione della pagina.Questa porzione di markup può essere gestito a questo punto dal javascript per andare a clonare questo codice, andarlo a mettere dentro lo Shadow DOM.In questo caso quindi ho la possibilità di definire del codice HTML in modo dichiarativo, quindi senza dover dare delle istruzioni per andare a disegnare le pagine, ma semplicemente descrivendole con linguaggio HTML e in modo molto pratico questo codice, questi elementi, vengono realizzati sulla pagina.Devo dire che, come vi dicevo, l'utilizzo dei web components è molto importante specie perché da una parte ci permettono di condividere il codice tra più team che magari utilizzano tecnologie front-end diverse.Dall'altra ha un altro vantaggio.Nell'ambito dei web components, dei micro front-end, come vi dicevo andremo a vedere la prossima settimana possono avere l'utilità di incapsulare alcune parti del front end magari scritte da team specifici e incapsulando questi blocchi di front end hanno la possibilità di non farli confliggere con altri e magari questi blocchi di front end uno usa angular uno usa react l'altro view quindi creano degli elementi in qualche modo chiusi che non interferiscono tra di loro che questa è come vi dicevo un altro vantaggio dell'utilizzo appunto dei web components utilizzando le API standard API di JavaScript.Questo è, diciamo, una view generale, un overview generale per la creazione dei web components in vanilla JavaScript.Naturalmente, devo dire che la trovo, venendo dal mondo React, trovo la creazione dei web components in vanilla JavaScript un po' verbosa.però devo anche dire che esistono tutta una serie di strumenti che ne semplificano la realizzazione.I primi due che mi vengono in mente sono Stencil, creato dal team di Ionic, famoso appunto per aver scritto un framework per la realizzazione di web application e di applicazioni mobile ibride, e è l'ItElements costola del progetto Polymer.Sono delle librerie che in qualche modo semplificano i passaggi per la creazione dei web components utilizzando appunto l'API dei custom elements shadow DOM.Quindi creano una sorta di livello di astrazione che ne semplifica l'utilizzo.Cosa però importante da sapere è che quindi esiste un API standard che ci permette di approcciare ai componenti web per cui le nostre API standard sono talmente moderne che in realtà potremo anche fare a meno dei framework se li utilizziamo solo, come vi dicevo all'apertura, per la creazione di web components Occhio però che spesso i framework mettono a disposizione un'altra serie di strumenti, come vi dicevo prima appunto il routing, lo stato, ma ne mettono a disposizione diversi.Quindi la scelta aspetta a voi.Spero che questo episodio vi sia piaciuto.Molto molto rapido, fortunatamente sono riuscito a stare attorno ai 20 minuti perché ormai le puntate stavano diventando davvero la divina commedia, quindi questo già mi fa piacere.attrezzatura di fortuna quindi anche il montaggio non sarà perfetto, abbiate pietà di me ma come vi ho spiegato su twitter e vi ho detto nell'introduzione il mio macbook pro con tutti i campioni per il montaggio con tutti i plug in è morto, sto usando un iMac che ho qua nella casa in Sardegna, il Il microfono è un microfono di fortuna rubato da amici.E nulla, quindi abbiate pazienza.Anche il prossimo episodio sarà un po' così, diciamo, "arrangiato" per poi arrivare a settembre.Spero con, di nuovo, il mio setup standard per gli episodi.Comunque, un'idea dei web components ce l'abbiamo fatta.Io vi do appuntamento alla prossima settimana, ma prima di salutarvi vi devo, come sempre, ricordare i nostri contatti.Potete scrivermi a info@gitbar.it oppure utilizzando Twitter @brainrepo.Tutti gli episodi con le note dell'episodio e le transcription, sempre se non esploso anche la lambda che fa le transcription, li trovate su www.gitbar.it.Naturalmente se volete rimanere aggiornati con i nuovi episodi il mio consiglio è quello di aprire il vostro client di podcast preferito, cercare Gitbar, c'è praticamente su tutti, basta digitare Gitbar nella casellina di ricerca e iscrivervi.In questo modo ogni settimana riceverete la notifica del nuovo episodio.Se proprio proprio le puntate vi sono piaciute, aprite l'applicazione Apple Podcast o iTunes e lasciate una recensione.Questo mi fa assolutamente piacere e soprattutto aiuta Gitbar a salire tra virgolette nelle classifiche e quindi a essere più trovabile.Tra l'altro ci tengo a dirvi che ho iscritto Gitbar al Festival de Podcasting come podcast emergenti.Per cui, anche in questo caso, se vi fa piacere potete aprire Instagram, cercare Festival del Podcasting, scorrendo dovreste trovare il post con il logo di Gitbar, mettete like, così insomma prendiamo un pochino più visibilità e la famiglia di Gitbar, degli ascoltatori di Gitbar cresce.Come vi dicevo ho come obiettivo per settembre di creare un gruppo telegram quindi vi vorrò numerosi e nulla io me ne vado in spiaggia un braccio da budoni e tutto ci sentiamo la prossima settimana ciao git bar il circolo dei full stack developer una volta a settimana ci troviamo davanti a due birre e con brain repo parliamo di linguaggi e tecniche di sviluppo web, di metodologie e degli strumenti immancabili nella cassetta degli attrezzi dei Full Stack DAF.[Musica]
