Styling e CSS

I Cascading Style Sheets (CSS) sono un linguaggio per determinare centralmente la presentazione di un documento anziché la formattazione rigida per testo e oggetti. La funzionalità a cascata del linguaggio è progettata per controllare le priorità tra gli stili utilizzando l'ereditarietà. Quando lavori su micro-frontend e crei una strategia per gestire le dipendenze, la funzionalità a cascata del linguaggio può essere una sfida.

Ad esempio, due micro-frontend coesistono sulla stessa pagina, ognuno dei quali definisce il proprio stile per l'elemento HTML. body Se ognuno recupera il proprio file CSS e lo allega al DOM utilizzando un style tag, il file CSS sostituisce il primo se entrambi hanno una definizione per elementi HTML comuni, nomi di classi o ID di elementi. Esistono diverse strategie per affrontare questi problemi, a seconda della strategia di dipendenza scelta per la gestione degli stili.

Attualmente, l'approccio più diffuso per bilanciare prestazioni, coerenza ed esperienza degli sviluppatori consiste nello sviluppo e nella manutenzione di un sistema di progettazione.

Sistemi di progettazione ‒ Un approccio basato sulla condivisione

Questo approccio utilizza un sistema per condividere lo stile quando appropriato, supportando al contempo divergenze occasionali per bilanciare coerenza, prestazioni ed esperienza degli sviluppatori. Un sistema di progettazione è una raccolta di componenti riutilizzabili, guidata da standard chiari. Lo sviluppo del sistema di progettazione è in genere guidato da un team con il contributo e il contributo di più team. In termini pratici, un sistema di progettazione è un modo per condividere elementi di basso livello che possono essere esportati come JavaScript libreria. Gli sviluppatori di Micro-frontend possono utilizzare la libreria come dipendenza per creare interfacce semplici componendo risorse disponibili predefinite e come punto di partenza per creare nuove interfacce.

Consideriamo l'esempio di un micro-frontend che necessita di un modulo. L'esperienza tipica degli sviluppatori consiste nell'utilizzare componenti predefiniti disponibili nel sistema di progettazione per comporre caselle di testo, pulsanti, elenchi a discesa e altri elementi dell'interfaccia utente. Lo sviluppatore non ha bisogno di scrivere uno stile per i componenti effettivi, ma solo per il loro aspetto insieme. Il sistema da compilare e rilasciare può utilizzare webpack Module Federation o un approccio simile per dichiarare il sistema di progettazione come dipendenza esterna, in modo che la logica del modulo sia impacchettata senza includere il sistema di progettazione.

Più microfrontend possono quindi fare lo stesso per occuparsi delle preoccupazioni condivise. Quando i team sviluppano nuovi componenti che possono essere condivisi tra più microfrontend, tali componenti vengono aggiunti al sistema di progettazione una volta raggiunta la maturità.

Uno dei principali vantaggi dell'approccio del sistema di progettazione è l'elevato livello di coerenza. Sebbene i microfrontend possano scrivere stili e occasionalmente sovrascrivere quelli del sistema di progettazione, ce n'è ben poco bisogno. I principali elementi di basso livello non cambiano spesso e offrono funzionalità di base che sono estendibili di default. Un altro vantaggio sono le prestazioni. Con una buona strategia di compilazione e rilascio, è possibile produrre pacchetti condivisi minimi che sono strumentati dalla shell dell'applicazione. È possibile migliorare ulteriormente quando più pacchetti specifici per microfrontend vengono caricati in modo asincrono su richiesta, con un ingombro minimo in termini di larghezza di banda di rete. Ultimo ma non meno importante, l'esperienza di sviluppo è ideale perché le persone possono concentrarsi sulla creazione di interfacce avanzate senza dover reinventare la ruota (come la scrittura JavaScript e il CSS ogni volta che è necessario aggiungere un pulsante a una pagina).

Il rovescio della medaglia è che un sistema di progettazione di qualsiasi tipo è una dipendenza, quindi deve essere mantenuto e talvolta aggiornato. Se più micro-frontend richiedono una nuova versione di una dipendenza condivisa, puoi utilizzare uno dei seguenti:

• Un meccanismo di orchestrazione in grado di recuperare occasionalmente più versioni di quella dipendenza condivisa senza conflitti

• Una strategia condivisa per far sì che tutti i dipendenti utilizzino una nuova versione

Ad esempio, se tutti i microfrontend dipendono dalla versione 3.0 di un sistema di progettazione ed è disponibile una nuova versione denominata 3.1 da utilizzare in modo condiviso, è possibile implementare dei flag di funzionalità per consentire la migrazione di tutti i microfrontend con il minimo rischio. Per ulteriori informazioni, consultate la sezione Feature flags. Un altro potenziale svantaggio è che i sistemi di progettazione di solito si occupano di qualcosa di più dello stile. Includono anche JavaScript pratiche e strumenti. Questi aspetti richiedono il raggiungimento del consenso attraverso il dibattito e la collaborazione.

L'implementazione di un sistema di progettazione è un buon investimento a lungo termine. È un approccio popolare e dovrebbe essere preso in considerazione da chiunque lavori su architetture frontend complesse. In genere richiede ingegneri di frontend e team di prodotto e progettazione per collaborare e definire meccanismi per interagire tra loro. È importante pianificare l'orario per raggiungere lo stato desiderato. È anche importante avere la sponsorizzazione della leadership in modo che le persone possano costruire qualcosa di affidabile, ben mantenuto e performante a lungo termine.

CSS completamente incapsulato ‒ Un approccio «share nothing»

Ogni micro-frontend utilizza convenzioni e strumenti per superare la funzionalità a cascata dei CSS. Un esempio è garantire che lo stile di ogni elemento sia sempre associato a un nome di classe anziché all'ID dell'elemento e che i nomi delle classi siano sempre unici. In questo modo, tutto è limitato ai singoli microfrontend e il rischio di conflitti indesiderati è ridotto al minimo. La shell dell'applicazione è in genere responsabile del caricamento degli stili dei microfrontend dopo che sono stati caricati nel DOM, anche se alcuni strumenti raggruppano gli stili utilizzando. JavaScript

Il vantaggio principale di non condividere nulla è il rischio ridotto di introdurre conflitti tra i micro-frontend. Un altro vantaggio è l'esperienza dello sviluppatore. Ogni micro-frontend non condivide nulla con gli altri micro-frontend. Il rilascio e il test in modo isolato sono più semplici e veloci.

Uno dei principali svantaggi dell'approccio share-nothing è la potenziale mancanza di coerenza. Non esiste alcun sistema per valutare la coerenza. Anche se l'obiettivo è duplicare ciò che è condiviso, diventa difficile trovare un equilibrio tra velocità di rilascio e collaborazione. Una mitigazione comune consiste nel creare strumenti per misurare la coerenza. Ad esempio, puoi creare un sistema per acquisire schermate automatiche di più micro-frontend renderizzati in una pagina con un browser headless. È quindi possibile rivedere manualmente gli screenshot prima di una versione. Tuttavia, ciò richiede disciplina e governance. Per ulteriori informazioni, consulta la sezione Bilanciamento dell'autonomia con l'allineamento.

A seconda del caso d'uso, un altro potenziale svantaggio sono le prestazioni. Se tutti i micro-frontend utilizzano una grande quantità di stile, il cliente deve scaricare molto codice duplicato. Ciò influirà negativamente sull'esperienza dell'utente.

Questo approccio basato sulla condivisione di nulla dovrebbe essere preso in considerazione solo per le architetture di microfrontend che coinvolgono solo pochi team o per i microfrontend che possono tollerare una bassa coerenza. Può anche essere un naturale passo iniziale mentre un'organizzazione sta lavorando su un sistema di progettazione.

Shared Global CSS ‒ Un approccio basato sulla condivisione totale

Con questo approccio, tutto il codice relativo allo styling viene archiviato in un repository centrale in cui i collaboratori scrivono CSS per tutti i micro-frontend lavorando su file CSS o utilizzando preprocessori come Sass. Quando vengono apportate modifiche, un sistema di compilazione crea un singolo pacchetto CSS che può essere ospitato in un CDN e incluso in ogni microfrontend dalla shell dell'applicazione. Gli sviluppatori di microfrontend possono progettare e creare le proprie applicazioni eseguendo il codice tramite una shell dell'applicazione ospitata localmente.

Oltre all'ovvio vantaggio di ridurre il rischio di conflitti tra microfrontend, i vantaggi di questo approccio sono la coerenza e le prestazioni. Tuttavia, il disaccoppiamento degli stili dal markup e dalla logica rende più difficile per gli sviluppatori capire come vengono utilizzati gli stili, come possono evolversi e come possono essere obsoleti. Ad esempio, potrebbe essere più rapido introdurre un nuovo nome di classe piuttosto che conoscere la classe esistente e le conseguenze della modifica delle sue proprietà. Gli svantaggi della creazione di un nuovo nome di classe sono la crescita delle dimensioni del pacchetto, che influisce sulle prestazioni, e la potenziale introduzione di incongruenze nell'esperienza utente.

Sebbene un CSS globale condiviso possa essere il punto di partenza di una monolith-to-micro-frontends migrazione, raramente è utile per le architetture di micro-frontend che coinvolgono più di uno o due team che collaborano insieme. Consigliamo di investire in un sistema di progettazione il prima possibile e di implementare un approccio basato sulla condivisione di nulla durante lo sviluppo del sistema di progettazione.