Tematică bazată pe componente cu Componenta unică a directorului Drupal

Tematica Drupal a fost un domeniu neatins de mult de o actualizare radicală. Sigur că există o mulțime de module disponibile pentru a face fluxul de lucru puțin mai ușor, dar abordarea ieșită din cutie pentru crearea unei teme personalizate a rămas mai mult sau mai puțin aceeași. Au existat discuții despre existența unui fel de mecanism de tematică bazat pe componente în interiorul nucleului Drupal de mult timp. Introduceți Single Directory Components (SDC) , care a fost în discuție de ceva timp printr-un modul contribuit gestionat de colaboratori proeminenți Drupal - Mateu Aguilo Bosch, Mike Herchel, Lauri Eskola și Dave Reid. Dar acum a intrat în nucleul Drupal (în prezent ca o caracteristică experimentală) în versiunea 10.1.

Această abordare bazată pe componente de tematizare a unei aplicații Drupal nu este nouă, dar în cele din urmă a ajuns la bază. Oferă o frontieră cu totul nouă pentru dezvoltatorii front-end de a-și organiza codul într-un mod mai ușor de întreținut, cu o curbă minimă de învățare. În SDC, toate fișierele necesare redării componentei (Twig, CSS, JS etc.) sunt grupate într-un singur director. SDC are potențialul de a revoluționa dezvoltarea front-end în Drupal, dând puterea dezvoltatorilor să folosească cele mai noi tehnici front-end, solidificând poziția Drupal ca un CMS robust și de perspectivă.

Abordarea tematică actuală a Drupal

Cel mai simplu mod de a lucra pe o temă Drupal a fost să adăugați marcajul la fișierele html.twig din folderele șabloane. Pentru stil și comportament, creăm fișiere CSS și JS în funcție de nevoia unei entități și le plasăm în folderele CSS și respectiv JS. Aceasta include meniul de antet temat, meniul de subsol, blocuri, regiuni, tipuri individuale de conținut și diferitele moduri de vizualizare ale acestora, vizualizări diferite etc. Aceste fișiere sunt apoi declarate în fișierul libraries.yml unde pot fi menționate și dependențele (dacă există). În acest fel, acestea pot fi încărcate la cerere sau disponibile la nivel global. În afară de aceasta, orice logică de preprocesare intră în fișierele .theme, avem breakpoints.yml pentru a vă ajuta cu design-urile receptive și, desigur, fișierul .info.yml fără de care tot efortul este o risipă.

În timp ce aceasta pare să fie multă muncă de făcut înainte de a face efectiv niște lucrări utile de front-end, au existat niște generatoare de cod standard, cum ar fi drush theme generate , care intenționează să genereze structura de foldere a unei teme într-un mod interactiv și să creeze un structura standard de foldere drupal.

Chiar dacă structura de mai sus funcționează suficient de bine pentru a începe un proiect și nu poate reprezenta nicio problemă pentru un proiect mic, poate deveni un blocaj pentru site-urile web ale întreprinderilor unde trebuie integrat un sistem de design mai sofisticat.

1. Lucrurile încep să devină aglomerate foarte repede. Vedem o mulțime de fișiere CSS și JS doar umplute până la refuz în folderele lor.
2. Dezvoltatorii se străduiesc să găsească codul pe care îl pot reutiliza sau extinde.
3. Apar probleme precum duplicarea codului, codul răspândit în fișiere, iadul specificului și conflictele CSS.
4. Acest lucru duce adesea la mai multe eforturi cheltuite pentru dezvoltarea ulterioară, unde se așteaptă ca dezvoltarea inițială să fi ajutat mai târziu.

Abordarea noastră a tematicii în Specbee

La Specbee, am standardizat modul în care ne creăm temele folosind un instrument NPM numit Drupal Theme Init, dezvoltat de noi de la zero, care este open-source. Fiind un generator Yeoman, acesta poate fi instalat cu ușurință cu NPM/Yarn, care apoi ajută în mod interactiv la generarea unei teme personalizate. Ideea inițială a temei Drupal este de a avea o abordare consecventă a modului în care fișierele de temă sunt schelete în conformitate cu practicile Drupal și de a ajuta dezvoltatorii să înceapă să lucreze la temă, fără a avea probleme de a seta fișierele de fiecare dată când încep un nou proiect. Ideea de bază a structurii este de a compartimenta SASS în componente folosind convenția BEM. Fiecare fișier CSS asociat cu o entitate precum bloc, vizualizare, tip de conținut etc. are propriul CSS generat și este atașat la acea entitate fie prin șablonul twig, fie prin preprocesare. Același lucru este valabil și pentru fișierele JS. Utilizarea extensivă a libraries.yml ne ajută să limităm cantitatea de CSS și JS pe care o redăm pe pagină.

Avantajul setării temei în acest fel este că avem un sistem pentru tematică bazată pe componente, fără a depinde de biblioteci sau pluginuri externe. Ne ajută să segregam bibliotecile CSS/JS pe baza componentelor care urmează să fie încărcate pe pagină, ceea ce ajută la performanță. Cu toate acestea, există încă limitări ale acestei abordări, mai ales atunci când proiectul crește în dimensiune. Segregarea componentelor în niveluri atomice devine puțin o povară, deoarece ne cere să menținem fișierul libraries.yml cu dependențele necesare. De asemenea, nu există o modalitate ușoară prin care putem face o integrare adecvată a unui sistem de proiectare cu structura actuală cu ușurință, deoarece va trebui să definim fiecare cale de componentă și dependența ei de către noi înșine în sistemul de proiectare, pentru a încărca componentele în acesta.

Ce este tematica bazată pe componente

În timp ce abordarea vanilie pare destul de simplă, au existat o mulțime de progrese făcute în ultima vreme prin module contribuite pentru a avea abordări mai bune. Una dintre abordările populare este imaginarea UI ca o colecție de unități reutilizabile și consistente numite componente . În cele mai multe cazuri, aceasta urmează Atomic Design în care fiecare componentă este separată în blocuri mai mici. Module precum UI Patterns, Components! sau biblioteci componente precum PatternLab, Fractal și Storybook au adus modalități inovatoare care au făcut ca dezvoltarea temelor să fie mai eficientă și mai robustă. Tematica bazată pe componente are un anumit avantaj față de tematica tradițională:

1. Unul dintre cele mai mari blocaje este dependența de backend, unde lucrul de front-end nu poate începe fără lucrul de backend. Acest lucru creează un decalaj. Folosind o abordare bazată pe componente, front-end-ul poate funcționa independent și fără cunoștințe profunde despre lucrurile Drupal.
2. Componentele pot fi create doar din designul disponibil cu substituenții necesari. Valorile pentru acești substituenți pot fi completate mai târziu, când munca de backend este finalizată
3. Acesta creează un flux de lucru în care pur și simplu nu schimbăm marcajul în folderul șabloane și nu îl stilăm conform cerințelor. Mai degrabă avem structuri mai mici stilate separat și apoi creăm o colecție de aceste unități mai mici în componente mai mari care pot fi folosite de șabloanele Drupal.
4. Acest lucru ajută la menținerea codului legat de fiecare componentă în mod izolat și creează șanse mai mici de efecte secundare.
5. Acesta confirmă consistența UX în întreaga aplicație.
6. Ajută la reducerea eforturilor depuse pentru configurarea funcției, deoarece modificările efectuate într-un singur loc se reflectă în zonele în care este utilizată.

Cum se face tematică bazată pe componente în Drupal

Una dintre modalitățile proeminente de a urmări dezvoltarea bazată pe componente este utilizarea PatternLab, care a fost introdus cu ceva timp în urmă. Inițial, a venit cu o ediție Drupal care este arhivată acum și înlocuită cu un pachet bazat pe noduri. Configurarea PatternLab necesită instalarea unui modul Componente care va ajuta la obținerea de markup din fișierele Twig în afara folderului de șabloane pentru Drupal. Aceasta este urmată de instalarea pachetului patternlab prin npm, care oferă opțiuni pentru a genera șabloane bazate pe twig sau mustache (evident twig pentru noi). Odată ce s-a făcut acest lucru, avem un ghid de stil pentru calcul, un cod boilerplate care ajută la crearea ghidului de stil și un folder de modele în care creăm componentele conform cerințelor. Aceste componente sunt apoi incluse în fișierele html.twig prezente în folderul șabloane.

Deși toți acești pași sunt bine de efectuat, există cazuri în care acest lucru este puțin dificil de configurat și are o curbă de învățare. Cel mai mare dezavantaj care vine cu Patternlab este că toate CSS-urile sunt agregate într-un singur fișier care apoi este aruncat în toate paginile (ceea ce este uneori și cazul cu JS-ul inclus cu acesta). Deși acest lucru nu contează inițial, deoarece ideea de bază este reutilizarea componentei, odată ce proiectul crește, acest lucru începe să afecteze performanța paginii.

Cum se face tematică bazată pe componente cu SDC

Având în vedere că versiunea inițială a SDC a intrat în nucleu ca modul experimental, a existat multă entuziasm în jurul ei. SDC a fost prezentată drept cea mai mare schimbare a tematicii Drupal de la introducerea Twig. SDC din nou nu este o soluție completă pentru echipa de dezvoltare front-end, ci o abordare bazată pe componente a tematicii, cu o structură de bază ieșită din cutie. Acest lucru poate fi în continuare extins cu un număr de module pentru un anumit tip de flux de lucru. Ideea de bază este că tot ceea ce are legătură cu o componentă rămâne într-un singur director. Acesta include fișierul Component Twig, JS, CSS, alte active și un singur fișier YAML cu schemă care declară proprietățile componentei.

Câteva beneficii imediate ale utilizării SDC:

1. Tot codul legat de o componentă este într-un singur director (după cum sugerează și numele!).
2. Bibliotecile pentru componentă sunt generate automat, ceea ce duce la o traumă mai mică de nedeclarare a acesteia în fișierul libraries.yml. Deși ar putea fi nevoie totuși să adăugăm dependențele la fișierul component.yml, acest lucru se face într-un singur loc, mai degrabă decât să sărim la fișierul libraries.yml.
3. Există o curbă de învățare mult mai mică pentru implementarea SDC. Dacă cunoașteți elementele de bază ale tematicii Drupal, tot ce trebuie să faceți este să activați acest modul și să începeți să scrieți componentele.
4. Puterea twig (include/extend/embed) este încă disponibilă, ceea ce ajută la reutilizarea codului.
5. Întrucât componentele sunt plugin-uri YML, care pot fi ușor descoperite de Drupal și pot fi schimbate cu ușurință de o componentă care are aceeași structură API.
6. Componentele pot fi redate și prin matrice de randare!
7. Oferă un mecanism bun pentru a integra biblioteci externe pentru a facilita un sistem de proiectare.
8. Pe măsură ce componentele sunt organizate, rezultatul este un aspect coerent al produsului final.
9. Codul devine mai testabil pe măsură ce avem unități (componente de citire) care pot fi testate independent
10. Deoarece definim schema în definiția YAML a unei componente, modulele pot crea automat formulare pentru a popula datele.

Deși este inclusă în prezent ca o caracteristică experimentală în nucleu, configurarea SDC este destul de ușoară. Presupunând că există o instalare Drupal 10.1.x:

1. Activați modulul de bază experimental SDC.

2. Creați sau utilizați o temă personalizată pentru a adăuga SDC. În scopul nostru, am creat o temă personalizată numită Ice Cream cu Olivero ca temă de bază.

3. În scopul nostru, să folosim pagina de bază care iese din cutie. L-am reutilizat adăugând un câmp Titlu personalizat și făcând câteva ajustări la afișaj, care arată apoi astfel:

4. Fișierul șablon twig constă din codul de bază:

5. Creați un folder numit componente în interiorul temei personalizate. Acest lucru este similar cu modul în care avem un folder de șabloane pentru șabloanele Drupal.

6. Deocamdată, ideea de bază este să stilezi titlul și descrierea, care vor fi reutilizabile în natură. Să creăm o componentă numită simplu-articol. Vor exista fișiere simple-article.component.yml și simple-article.twig de care vom solicita. În afară de asta, vom adăuga și simple-article.css pentru stil.

7. Să creăm fișierul simple-article.twig . Vom avea un marcaj de bază pentru asta.

8. Adăugați fișierul simple-article.component.yml cu schema menționată în https://www.drupal.org/node/3352951. Ideea este de a defini care vor fi intrările în fișierul twig. Va arata cam asa pentru noi:

9. Să adăugăm un stil de bază la componenta din simple-article.css .

10. Goliți memoria cache.

11. Abracadabra! Componenta este acum gata de utilizare. Dar mai trebuie folosit . Fără asta, componenta rămâne inactivă în folderul componente.

12. Includeți această componentă în fișierul șablon necesar (acesta este fișierul html.twig sub folderul șabloane din tema personalizată) cu formatul [theme_name:component-name]. Observați instrucțiunea include în care adăugăm variabilele twig pentru a fi utilizate în componentă.

13. Componenta este acum redată cu noul nostru marcaj și un stil mai bun.

14. Observați marcajul. Dacă depanarea ramurilor este activată, primim și câteva pictograme speciale cu componenta noastră SDC redată.

Si asta e!

Referințe

• 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

Gânduri finale

Odată cu modul în care a fost construit SDC, va exista o dezvoltare de mare intensitate în jurul ei. Una dintre melodiile populare este că modulele vor detecta automat componentele și vor introduce formele lor respective în Layout Builder, CKEditor, Paragraphs, Blocks, Fields etc! În plus, SDC chiar acum joacă frumos cu Storybook printr-un modul contribuit numit CL Server (care a fost întreținut de menținătorii proiectului SDC). Există deja și alte module precum CL Devel, CL Generator și chiar modele UI care sunt construite în jurul SDC.

Acest lucru ne va ajuta, de asemenea, să ne actualizăm propriul generator de teme (Drupal Theme Init), despre care am discutat mai devreme, pentru a oferi opțiunea de a folosi SDC împreună cu un sistem de design, de preferință Storybook. Acest lucru va ajuta pe oricine să demareze implementarea SDC, deschizând instantaneu calea pentru o mai bună dezvoltare a temei.

Dacă doriți să citiți mai mult conținut atât de interesant pe Drupal, abonați-vă astăzi la newsletter-ul nostru săptămânal!