Hyva ha portato notevoli cambiamenti nel modo di sviluppare su Magento 2. Uno degli aspetti più particolari per un frontend developer è senza dubbio il cambio di paradigma con gli stili degli elementi. Mentre prima con Magento2 avevamo un framework basato molto sulle relazioni e spesso con una ingegnerizzazione del less fino troppo complessa per l’uso quotidiano di un frontend, con Hyva si è passato a Tailwind CSS e alla migrazione degli stili verso un aspetto più funzionale.
La separazione tra relazioni e classi ha portato sicuramente dei vantaggi nel mantenimento di una interfaccia nel lungo periodo. Questo limita notevolmente la crescita dei fogli di stili nel corso del tempo e permette uno sviluppo più rapido dell’intera interfaccia. Una spiegazione più dettagliata dei vantaggi in questo tipo di approccio e dell’utility first la puoi trovare consultando l’interessante articolo di Adam Wathan:
CSS Utility Classes and “Separation of Concerns
Ovviamente questo tipo di approccio lo si è potuto adottare grazie al fatto che Hyva riscrive da zero l’intero template system di Magento permettendo di ridefinire l’html a proprio piacimento.
Nello sviluppo con Tailwind CSS però è bene osservare alcune buone pratiche di sviluppo per evitare di tenere più snello ed efficiente possibile il proprio progetto frontend. Di seguito ne vedremo alcuni.
Usa una design guide definita
L’approccio tradizionale di sviluppo frontend consisteva nell’adattare gli stili di ogni pagina e di ogni area secondo un mockup o progetto grafico ben definito e spesso discordante nelle varie sezioni. Pensa ad esempio ai vari pulsanti, form o semplici margini che cambiano ad ogni sezione. Ci si ritrova spesso a definire altezze e margini diversi per ogni elemento di ogni pagina.
Sebbene ciò non sia sempre possibile, cerca di fare in modo che il designer progetti l’interfaccia con una design guide ben definita, stabilendo colori, misure e stili ben precisi e coerenti su tutta l’interfaccia. Ciò permetterà di avere molte meno regole e combinazioni da inserire sul file config di Tailwind CSS e di conseguenza il foglio di stile generato sarà sicuramente più leggero.
Usa adeguatamente i componenti
Quando si sviluppa con Tailwind CSS usano l’approccio utility first, potrebbe capitare spesso di ripetere gli stessi stili per determinati elementi. Se alcuni elementi si ripetono con costanza e sempre uguali, potete decidere di astrarre le utility class in un componente separato che può essere richiamato in modo veloce per ogni elemento.
Maggiori informazioni su come utilizzare i componenti potete trovarli nella pagina docs di Tailwind CSS relativa ai componenti.
Da tenere a mente che i componenti devono essere creati solo per elementi che possono essere ricondotti allo stesso componente. Usare questo approccio solamente per raggruppare alcune classi è sbagliato. Ogni componente inoltre non deve ereditare gli stili di altri componenti con l’utilizzo di @apply, altrimenti si rischia di creare meccanismi di dipendenze di stili che al crescere del progetto si rischia di non controllare più. Quindi scrivere “.button-primary { @apply .button; }” è scorretto mentre è buona norma tenere .button .button-primary separati.
Tenere ordinate le classi
Scrivere in modo ordinato il codice permette una più rapida lettura sia in fase di test che successivo rework. Nel caso di TailwindCSS l’ordinamento delle utility class secondo un certo criterio permette una lettura più agevole. Uno degli approcci più comodi è quello concentrico del CSS (Concentric CSS approach) dove si da priorità alla visualizzazione e ai parametri del box per poi entrare via via dalle caratteristiche esterne a quelle interne fino a quelle specifiche del contenuto.
Semplificare e ridurre le utility class
Usare meno classi possibili rende l’html più piccolo e leggero. Ad esempio visto che il design è mobile first, è opportuno usare i prefix solamente per alcuni breakpoint. Perciò anziché scrivere “sm:mb-2 md:mb-4 lg:mb-4 xl:mb-4” è sufficiente utilizzare solo “sm:mb-2 md:mb-4”. Allo stesso modo è più comodo usare “my-2 p-4” anziché tenere esplosi i vari margini e padding con “mt-2 mb-2 pt-4 pb-4 pl-4 pr-4”.
Less is more
Se hai già avuto modo di lavorare con Hyva probabilmente avrai già notato che il design standard utilizza un design minimal che contiene delle classi e degli stili non sempre utili (es. le card o le outline per vari elementi). Se il tuo design non utilizza questi stili potresti essere tentato dal fare un override con le utility class ogni qualvolta incontri degli stili che non ti piacciono o non ti servono. La via migliore però è ovviamente quella di rimuovere tutto ciò che non serve ed è meglio effettuare una sostituzione degli stili piuttosto che fare un override tramite il meccanismo di specificità delle classi.
Annotare le classi dinamiche
Sul tema vi sono determinate classi (es. quelle del body o dichiarate lato xml) che non sono esplicitate nel template e di conseguenza il purge non li troverà, rimuovendo certe direttive nella build per la production. Questo comporta dei risultati inattesi quando si passa appunto dalla build dev a quella prod. Per questo motivo è buona pratica ricordarsi di annotare queste classi in un html separato (non utilizzato) in modo che il purge trovandoli non vada a ripulire il css.
Abbiamo visto le principali best practices da tenere a mente con Hyva e nello specifico con Tailwind CSS. Vi sono diversi altri accorgimenti che occorre tenere a mente su questo nuovo frontend ma sarà sicuramente materiale per un prossimo articolo.
Se hai dubbi o ti vengono in mente altre possibili buone pratiche di sviluppo scrivicelo pure nei commenti 🙂