Temi basati su componenti con Single Directory Component di Drupal

La tematizzazione di Drupal è stata un'area a lungo non toccata da un aggiornamento radicale. Sicuramente ci sono tonnellate di moduli di contributo disponibili per rendere il flusso di lavoro un po' più semplice, ma l'approccio predefinito per la creazione di un tema personalizzato è rimasto più o meno lo stesso. Per molto tempo si è parlato di avere una sorta di meccanismo di tematizzazione basato su componenti all'interno dello stesso core di Drupal. Inserisci Single Directory Components (SDC) , che è stato in discussione per un bel po' di tempo attraverso un modulo di contributo gestito da importanti contributori di Drupal - Mateu Aguilo Bosch, Mike Herchel, Lauri Eskola e Dave Reid. Ma ora è entrato nel cuore di Drupal (attualmente come funzionalità sperimentale) nella versione 10.1.

Questo approccio basato sui componenti del tematizzazione di un'applicazione Drupal non è nuovo, ma alla fine è arrivato al nocciolo. Offre una frontiera completamente nuova per gli sviluppatori front-end per organizzare il proprio codice in un modo più gestibile con una curva di apprendimento minima. All'interno di SDC, tutti i file necessari per il rendering del componente (Twig, CSS, JS, ecc.) sono raggruppati in un'unica directory. SDC ha il potenziale per rivoluzionare lo sviluppo front-end in Drupal consentendo agli sviluppatori di sfruttare le più recenti tecniche front-end, consolidando la posizione di Drupal come CMS solido e lungimirante.

L'attuale approccio tematico di Drupal

Il modo più semplice per lavorare su un tema Drupal è stato quello di aggiungere il markup ai file html.twig all'interno delle cartelle dei template. Per lo stile e il comportamento, creiamo file CSS e JS in base alle esigenze di un'entità e li inseriamo rispettivamente nelle cartelle CSS e JS. Ciò include il menu dell'intestazione del tema, il menu del piè di pagina, i blocchi, le regioni, i singoli tipi di contenuto e le loro diverse modalità di visualizzazione, diverse visualizzazioni, ecc. Questi file vengono quindi dichiarati nel file library.yml dove possono essere menzionate anche le dipendenze (se presenti). In questo modo possono essere caricati su richiesta o resi disponibili a livello globale. A parte questo, qualsiasi logica di pre-elaborazione va nei file .theme, abbiamo i breakpoints.yml per aiutare con i design reattivi e, naturalmente, il file .info.yml senza il quale tutto lo sforzo è uno spreco.

Anche se sembra che ci sia molto lavoro da fare prima di svolgere effettivamente un utile lavoro di frontend, ci sono stati alcuni generatori di codice boilerplate come drush theme generate , che intendono generare la struttura delle cartelle di un tema in modo interattivo e creare un struttura di cartelle drupal standard.

Anche se la struttura di cui sopra funziona abbastanza bene per avviare un progetto e non può rappresentare un problema per un piccolo progetto, può diventare un collo di bottiglia per i siti Web aziendali in cui è necessario integrare un sistema di progettazione più sofisticato.

1. Le cose iniziano a diventare ingombra molto rapidamente. Vediamo molti file CSS e JS appena riempiti fino all'orlo nelle loro cartelle.
2. Gli sviluppatori faticano a trovare il codice che possono riutilizzare o estendere.
3. Problemi come la duplicazione del codice, la diffusione del codice tra i file, l'inferno di specificità e i conflitti CSS emergono.
4. Questo spesso porta a maggiori sforzi spesi per lo sviluppo successivo dove si prevede che lo sviluppo iniziale avrebbe aiutato in seguito.

Il nostro approccio alla tematizzazione in Specbee

In Specbee, abbiamo standardizzato il modo in cui creiamo i nostri temi utilizzando uno strumento NPM chiamato Drupal Theme Init sviluppato da noi da zero che è open-source. Essendo un generatore Yeoman, può essere facilmente installato con NPM/Yarn che poi aiuta in modo interattivo nella generazione di un tema personalizzato. L'idea dell'init del tema Drupal è di avere un approccio coerente al modo in cui i file del tema vengono impalcati seguendo le pratiche Drupal e per aiutare gli sviluppatori a iniziare a lavorare sul tema senza il fastidio di impostare i file ogni volta che iniziano un nuovo progetto. L'idea di base della struttura è compartimentare SASS in componenti utilizzando la convenzione BEM. Ogni file CSS associato a un'entità come blocco, vista, tipo di contenuto, ecc. ha il proprio CSS generato ed è collegato a tale entità tramite il modello twig o la preelaborazione. Lo stesso vale per i file JS. L'uso estensivo di library.yml ci aiuta a limitare la quantità di CSS e JS che rendiamo sulla pagina.

Il vantaggio di impostare il tema in questo modo è che abbiamo un sistema in atto per il tema basato su componenti senza dipendere da librerie o plug-in esterni. Ci aiuta a separare le librerie CSS/JS in base ai componenti da caricare sulla pagina, il che aiuta con le prestazioni. Tuttavia, ci sono ancora dei limiti a questo approccio, soprattutto quando il progetto cresce di dimensioni. La segregazione dei componenti in livelli atomici diventa un po' un peso in quanto ci richiede di mantenere il file library.yml con le dipendenze richieste. Inoltre, non esiste un modo semplice per integrare facilmente un sistema di progettazione con la struttura corrente poiché dovremo definire da soli ogni percorso di componente e la sua dipendenza anche nel sistema di progettazione, per caricare i componenti in esso.

Cos'è la tematizzazione basata su componenti

Mentre l'approccio vaniglia sembra abbastanza semplice, negli ultimi tempi sono stati compiuti enormi progressi attraverso moduli di contributo per avere approcci migliori. Uno degli approcci popolari consiste nell'immaginare l'interfaccia utente come una raccolta di unità riutilizzabili e coerenti denominate componenti . Nella maggior parte dei casi, questo segue Atomic Design in cui ogni componente è segregato in blocchi di costruzione più piccoli. Moduli come UI Patterns, Components! o librerie di componenti come PatternLab, Fractal e Storybook hanno portato modi innovativi che hanno reso lo sviluppo di temi più snello e robusto. Il tema basato sui componenti ha un certo vantaggio rispetto al tema tradizionale:

1. Uno dei maggiori colli di bottiglia è la dipendenza dal backend, dove il lavoro del frontend non può iniziare senza il lavoro del backend. Questo crea un ritardo. Utilizzando un approccio basato sui componenti, il front-end può lavorare in modo indipendente e senza una conoscenza approfondita delle cose Drupal.
2. I componenti possono essere creati solo dal design disponibile con i segnaposto richiesti. I valori per questi segnaposto possono essere riempiti in un secondo momento quando il lavoro di back-end è stato completato
3. Crea un flusso di lavoro in cui semplicemente non modifichiamo il markup nella cartella dei modelli e lo stiliamo secondo i requisiti. Piuttosto abbiamo strutture più piccole stilizzate separatamente e quindi creiamo una raccolta di queste unità più piccole in componenti più grandi che possono essere utilizzate dai modelli Drupal.
4. Questo aiuta a mantenere isolato il codice relativo a ciascun componente e crea minori possibilità di effetti collaterali.
5. Conferma la coerenza dell'esperienza utente in tutta l'applicazione.
6. Aiuta a ridurre gli sforzi spesi per configurare la funzione poiché le modifiche apportate in un punto si riflettono nelle aree in cui viene utilizzata.

Come creare temi basati su componenti in Drupal

Uno dei modi principali per seguire lo sviluppo basato sui componenti è l'utilizzo di PatternLab, che è stato introdotto parecchio tempo fa. Inizialmente è arrivato con un'edizione Drupal che ora è archiviata e sostituita da un pacchetto basato su nodi. L'impostazione di PatternLab richiede l'installazione di un modulo Componenti che aiuterà a ottenere il markup dai file Twig al di fuori della cartella dei modelli per Drupal. Questo è seguito dall'installazione del pacchetto patternlab tramite npm che offre opzioni per generare modelli basati su twig o baffi (ovviamente twig per noi). Una volta fatto ciò, abbiamo una guida di stile pronta per il calcolo, del codice boilerplate che aiuta nella creazione della guida di stile e una cartella di modelli in cui creiamo i componenti in base ai requisiti. Questi componenti vengono quindi inclusi nei file html.twig presenti all'interno della cartella dei modelli.

Sebbene tutti questi passaggi vadano bene, ci sono casi in cui questo è un po' difficile da configurare e ha un po' di curva di apprendimento. Il più grande svantaggio che viene fornito con Patternlab è che tutto il CSS è aggregato in un singolo file che viene poi scaricato in tutte le pagine (che a volte è anche il caso del JS incluso). Anche se inizialmente questo non ha importanza poiché l'idea di base è la riusabilità del componente, una volta che il progetto cresce, questo inizia a influire sulle prestazioni della pagina.

Come creare temi basati su componenti con SDC

Con la versione iniziale di SDC che entra nel nucleo come modulo sperimentale, c'è stata molta eccitazione attorno ad essa. SDC è stato pubblicizzato come il più grande cambiamento nel tema Drupal dall'introduzione di Twig. SDC ancora una volta non è una soluzione completa per il team di sviluppo del frontend, ma un approccio alla tematizzazione basato sui componenti con una struttura di base pronta all'uso. Questo può ancora essere esteso con un numero di moduli per un certo tipo di flusso di lavoro. L'idea di base è che tutto ciò che riguarda un componente rimane all'interno di una singola directory. Ciò include il file Component Twig, JS, CSS, altre risorse e un singolo file YAML dello schema che dichiara le proprietà del componente.

Alcuni vantaggi immediati dell'utilizzo di SDC:

1. Tutto il codice relativo a un componente si trova in un'unica directory (come suggerisce il nome!).
2. Le librerie per il componente vengono generate automaticamente, il che porta a un trauma minore di non dichiararlo nel file library.yml. Anche se potremmo ancora aver bisogno di aggiungere le dipendenze al file component.yml, questo viene fatto in un unico punto piuttosto che saltare al file library.yml.
3. C'è una curva di apprendimento molto più breve per implementare la SDC. Se conosci le basi della tematizzazione di Drupal, tutto ciò che devi fare è abilitare questo modulo e iniziare a scrivere i componenti.
4. La potenza di twig (include/extend/embed) è ancora disponibile, il che aiuta nella riusabilità del codice.
5. Poiché i componenti sono plug-in YML, che possono essere facilmente scoperti da Drupal e possono essere facilmente scambiati da un componente con la stessa struttura API.
6. I componenti possono anche essere renderizzati tramite array di rendering!
7. Fornisce un buon meccanismo per integrare librerie esterne per facilitare un sistema di progettazione.
8. Man mano che i componenti sono organizzati, il risultato è un aspetto coerente del prodotto finale.
9. Il codice diventa più testabile poiché disponiamo di unità (componenti di lettura) che possono essere testate in modo indipendente
10. Poiché definiamo lo schema all'interno della definizione YAML di un componente, i moduli possono creare automaticamente moduli per popolare i dati.

Sebbene sia attualmente inclusa come funzionalità sperimentale nel core, configurare SDC è abbastanza semplice. Supponendo che ci sia un'installazione di Drupal 10.1.x:

1. Abilitare il modulo core SDC sperimentale.

2. Crea o usa un tema personalizzato per aggiungere SDC. Per il nostro scopo abbiamo creato un tema personalizzato chiamato Ice Cream con Olivero come tema di base.

3. Per il nostro scopo, usiamo la pagina di base che esce dalla scatola. L'ho riproposto aggiungendo un campo Titolo personalizzato e apportando alcune modifiche al display che appare così:

4. Il file twig modello è costituito da codice di base:

5. Crea una cartella chiamata componenti all'interno del tuo tema personalizzato. Questo è simile a come abbiamo una cartella dei modelli per i modelli Drupal.

6. Per ora, l'idea di base è di dare uno stile al titolo e alla descrizione, che saranno riutilizzabili in natura. Creiamo un componente chiamato articolo semplice. Ci saranno i file simple-article.component.yml e simple-article.twig di cui avremo bisogno. A parte questo, aggiungeremo anche simple-article.css per lo styling.

7. Creiamo il file simple-article.twig . Avremo un markup di base per questo.

8. Aggiungi il file simple-article.component.yml con lo schema menzionato in https://www.drupal.org/node/3352951. L'idea è definire quali saranno gli input per il file twig. Sarà simile a questo per noi:

9. Aggiungiamo alcuni stili di base al componente in simple-article.css .

10. Svuota la cache.

11. Abracadabra! Il componente è ora pronto per l'uso. Ma deve ancora essere utilizzato . Senza questo, il componente rimane inattivo nella cartella dei componenti.

12. Includere questo componente nel file modello richiesto (questo è il file html.twig nella cartella dei modelli nel tema personalizzato) con il formato [nome_tema:nome-componente]. Notare l'istruzione include in cui stiamo aggiungendo le variabili twig da utilizzare nel componente.

13. Il componente ora viene renderizzato con il nostro nuovo markup e uno stile migliore.

14. Notare il markup. Se il twig debug è abilitato, otteniamo anche alcune icone speciali con il nostro componente SDC renderizzato.

E questo è tutto!

Riferimenti

• https://www.drupal.org/docs/develop/theming-drupal/using-single-directory-components/about-single-directory-components
• https://www.drupal.org/project/sdc
• https://herchel.com/articles/creating-your-first-single-directory-component-within-drupal

Pensieri finali

Con il modo in cui è stata costruita la DSC, ci sarà uno sviluppo ad alta intensità attorno ad essa. Una delle tracce popolari è che i moduli rileveranno automaticamente i componenti e inseriranno i rispettivi moduli in Layout Builder, CKEditor, Paragraphs, Blocks, Fields, ecc.! Inoltre, SDC in questo momento funziona bene con Storybook attraverso un modulo di contributo chiamato CL Server (che è stato mantenuto dai manutentori del progetto SDC). Esistono già altri moduli come CL Devel, CL Generator e persino UI Patterns che vengono costruiti attorno a SDC.

Questo ci aiuterà anche ad aggiornare il nostro generatore di temi (Drupal Theme Init) di cui abbiamo discusso in precedenza per offrire la possibilità di utilizzare SDC insieme a un sistema di progettazione in atto, preferibilmente Storybook. Ciò aiuterà chiunque a dare il via all'implementazione di SDC aprendo immediatamente la strada a un migliore sviluppo del tema.

Se desideri leggere altri contenuti così interessanti su Drupal, iscriviti oggi stesso alla nostra newsletter settimanale!