În acest an am avut mai multe prezentări despre Ghidul de stil SC5. în care am împărtășit experiența utilizării instrumentului pentru proiectele unuia dintre clienții noștri - operatorul de telefonie mobilă Elisa. Având în vedere că Elisa este o companie imensă cu o mulțime de site-uri pe care este necesar să mențină un stil unificat, nu este surprinzător faptul că ghidul de stil SC5 ca instrument acolo este foarte util. Dar proiectele mici? Merită pentru ei să facă un ghid de stil? Eu însumi nu știam răspunsul la această întrebare și am vrut să experimentez. Ca site de testare, mi-am luat propriul blog.
Stilul live al blogului blogului meu arată astfel: varya.me/styleguide. Puteți vedea întreaga interfață, împărțită în blocuri, fiecare dintre acestea implicând o componentă independentă. Încă nu m-am uitat la interfața blogului meu în acest fel și mă face să mă gândesc și la arhitectura CSS a proiectului. Dar să vorbim despre totul în ordine.
Configurarea Ghidului de stil SC5
Totul începe cu instalarea pachetului
După aceea, am putut genera un site web pentru ghidul de stil. Pentru a face asta, aveam nevoie de două sarcini de gulp.
Aveam nevoie să scot puțin din configurația oferită în documentație pentru a-mi rezolva sarcinile. Voi scrie despre asta în detaliu.
Utilizând parametrul appRoot
Ghidul meu de stil nu este în rădăcina domeniului, ci într-un director numit stilguide. Acest lucru trebuie raportat instrumentului, astfel încât aplicația generată de acesta să utilizeze legăturile corecte:
Dar, de fapt, avem nevoie de un alt truc. Componentele mele sunt scrise în i-bem.js și sunt inițializate automat de domReady. Acesta este exact ceea ce aveți nevoie pentru un blog, deoarece paginile sunt statice și toate marcajul HTML este încărcat imediat. Dar site-ul ghidului de stil este SPA (aplicație de o pagină), și acolo nu a funcționat. Componentele sunt desenate pe paginile capului de staționare în zbor, și este evident că acest lucru se întâmplă mai târziu pe domReady. Adică nu sunt inițializate automat. Din fericire, puteți utiliza ghidul de stil: evenimentul Revenit pe obiectul ferestrei. care ghidul de stil SC5 creează de fiecare dată când o componentă este reprogramată. Am inițializat componentele acestui eveniment, adică imediat după ce apar pe pagină. Această inițializare este necesară numai pe site-ul ghidului de stil, deci acest cod nu este inclus în ansamblul general și este conectat la ghidul de stil ca fișier suplimentar.
Ghid de stil ca pagină statică
Pentru modul de dezvoltare, Ghidul de stil SC5 pornește serverul, ceea ce distruge toate căile spre directorul rădăcină, de unde este distribuit SPA-ul generat. Dacă doriți să utilizați rezultatul pe serverul dvs., va trebui să vă ocupați singur de această rutare. Dar, în cazul meu, site-ul este localizat pe paginile GitHub, aceasta este o găzduire statică și nu există nici o rutare furnizată. Cu toate acestea, pentru acest caz, există o setare de disableHtml5Mode: true. Ea spune generatorului că aplicația ar trebui să aibă legături vechi bune cu un #. Deci, totul funcționează.
Componente de documentare
Chiar înainte de introducerea ghidului de stil, am avut toate CSS scris pe BEM, adică cu o abordare componentă. Pentru ghidul de stil, trebuie doar să specificați structura componentelor și să documentați blocurile folosind KSS.
Structurarea codului
S-a dovedit că structura de fișiere oferită de BEM nu este cea mai bună soluție pentru dezvoltarea unui stilistic live. Pe sistemul de fișiere, toate componentele sunt reprezentate de o listă lungă:
Adică, componentele atomice mici nu diferă de blocurile pentru structura paginii (cum ar fi Antet sau subsol), de la blocuri din bara laterală sau de la CSS la widget-uri terță parte. Desigur, o structură plană este mai convenabilă pentru colectori, dar din punct de vedere al dezvoltării este nevoie de un fel de catalogare.
Pentru aceasta, am făcut un fișier numit overview.css. în care nu există niciun CSS activ, dar mă ajută să organizez blocurile. Am 5 secțiuni acolo și în fiecare dintre componentele legate de el:
Ignor listele mele de blocuri, pentru că nu afectează codul în nici un fel. Dar descrierile secțiunilor rămân.
Descrierea blocurilor
În documentație, componentele sunt desenate separat pentru fiecare modificator: varya.me/styleguide/#/section/1.5.1
Pentru componente complexe care sunt utilizate intern de către alții, am folosit o etichetă cheie
Din acest motiv, documentația într-un cod de dimensiune acceptabilă, iar pe site-ul totul este dezvăluit în întregime: varya.me/styleguide/#/section/4.1
Dezvoltare condusă de stilul-ghid
Dacă în ghidul de stil rezultat în câmpul de căutare introduceți "logo", atunci veți vedea toate componentele care utilizează logo-ul! Căutarea este efectuată pe tot codul. În mod similar, puteți căuta componente în marcajul utilizat . Sau în stilul cărora există font.
Îmi place în special că puteți căuta și marca. Acest lucru poate fi folosit în timpul refactorizării. De exemplu, schimbarea intrării, pot găsi toate blocurile folosind și să văd dacă acestea sunt rupte.
Deși, de fapt, acesta este doar un mic plus față de principalul avantaj al utilizării ghidului de stil. În opinia mea, principalul său avantaj este demonstrarea erorilor de aspect.
În CSS-ul blogului meu, înainte de introducerea ghidului de stil, sa folosit o abordare componentă. Având în vedere experiența mea BEM, am fost 100% sigură că componentele au fost scrise bine. Dar chiar și o astfel de dezvoltare a componentelor a avut loc încă din punctul de vedere al paginii. Înainte ca blocurile să fie încorporate în blog, le-am făcut pe o pagină statică separată. Adică, în afara paginii, acestea nu au existat niciodată.
Blocurile au fost dezvoltate ca independente, am scris codul, încercând să-l realizez. Dar când au fost plasate împreună pe aceeași pagină, nu au fost niciodată independente.
După ce Ghidul stilului SC5 le-a atras magicale separat, văd că blocul de logo-uri este aliniat la dreapta. Deși de ce ar face asta? Evident, aceasta este greșeala mea, făcută când am introdus logoul din blocul Header.
Același lucru sa întâmplat și cu comutatorul de limbă. este, de asemenea, aliniat la dreapta.
Desigur, astfel de descoperiri implică o refactorizare rapidă :-)
Și, în plus, trebuie să spunem că experimentul nu este terminat. Există și alte descoperiri pentru postări noi.