TailwindCSS: @apply al posto delle utility inline?

[Byloth]

Arriva tutto dalla PR #31...

In questa PR, mi son permesso di apportare questa modifica e rimuovere le classi di Tailwind inline dall'HTML e spostarle all'interno del CSS.

Sul gruppo Telegram -in realtà- questa domanda è stata fatta più e più volte...
E -più volte- non si è mai arrivati davvero ad una risposta concreta, per il semplice fatto che -ognuno- ha il suo modo di lavorare.

MA...
Sono sempre stati riconosciuti in maniera positiva i benefit dello scrivere lo stile usando l'@apply...

• L'HTML non ne viene appesantito: si evitano ripetizioni e la pagina finale inviata al browser pesa leggermente meno.
• In fase di debug, si è notevolmente agevolati: l'HTML è piu chiaro da leggere, meno confusionario e la disattivazione di una regola CSS su un singolo componente (tramite l'apposito tool con le "checkbox" dei DevTools) non spacca lo stile di tutti gli altri componenti che usano la stessa classe all'interno della pagina.
• È possibile scrivere lo stile in maniera più ordinata; al posto di avere tutte le regole nell'attributo class del componente, si possono dividere in molteplici righe -con molteplici @apply- suddivisi per tipologia (gli @apply relativi alla spaziatura, gli @apply relativi ai colori, gli @apply relativi alle trasformazioni, ecc...).

---

Per quanto mi riguarda, questa deve essere una presa di posizione forte della community; dobbiamo dare il buon l'esempio!
Tailwind è un strumento ottimo ma dev'essere usato bene e con tutti i crismi.

Voi cosa ne pensate?

[Byloth]

Anche il CSS risultante, ovviamente, dovrà essere scritto bene...
Nella PR ho proposto un'applicazione "ibrida" del naming BEM a una nidificazione degli stili...

Se "nidifico" usando il BEM non ho bisogno di nidificare fisicamente la classe; viceversa, se per semplicità o lettura della classe stessa non applico la gerarchia BEM, allora nidifico all'interno della regola padre.

Trovate un esempio pratico qui:
https://github.com/vuejsita/vuejsita.github.io/pull/31/files#diff-02281a80fab758cb4e8e8359b222a8a5afeaa9d5a7ba858f15d852f1f8969ecfR74-R111

---

Nella mia testa è sensato; magari -fuori- lo è un po' meno... 🥹😅

[longo-andrea]

Io purtroppo dove lavoro ora utilizziamo tailwind inline 😓 questo solo per dire che mio malgrado sono abbastanza in grado di navigare/debuggare anche se decidessimo di adottare questo stile.
Però sono più che favorevole all'approccio BEM + apply, quindi voterei per lavorare come fatto nella PR che hai linkato

[sariodesign]

A me non convince la soluzione ibrida, o utilizziamo tailwind così con le utility-first, qui trovate una motivazione da parte loro, con relativi articoli di approfondimento.

Oppure scriviamo css/scss con metodologia BEM, eliminando tailwind, ma formattando bene il 'naming', allego due articoli con esempi, con focus sugli "elements":
https://en.bem.info/methodology/quick-start/#element
https://sparkbox.com/foundry/bem_by_example

La soluzione ibrida ci porterà a duplicare il css, non solo importiamo le utility-class di Tailwind, ma dopo le inseriamo in un altro css/scss, andando appunto a duplicare proprietà e valori.

[Byloth]

Oh, figo... Super interessante!

Ne cito un estratto:

If you start using @apply for everything, you are basically just writing CSS again and throwing away all of the workflow and maintainability advantages Tailwind gives you, for example:

• You have to think up class names all the time — nothing will slow you down or drain your energy like coming up with a class name for something that doesn’t deserve to be named.
• You have to jump between multiple files to make changes — which is a way bigger workflow killer than you’d think before co-locating everything together.
• Changing styles is scarier — CSS is global, are you sure you can change the min-width value in that class without breaking something in another part of the site?
• Your CSS bundle will be bigger — oof.

---

Non sono del tutto d'accordo con il «... throwing away all of the workflow and maintainability advantages Tailwind gives you»...
I benefici in termini di riusabilità e di configurabilità delle sue utility class permangono, a mio avviso... A prescindere da dove si vada a scriverle!

Inoltre, l'unico punto realmente sensato -applicato al contesto del nostro progetto- è ovviamente il punto 4 ma che ha decisamente una sua rilevanza non tralasciabile!

In tutta onestà, immaginavo che Tailwind fosse più intelligente, in termini di tree-shaking...
Avevo intuito che le regole CSS venissero incluse nel bundle finale solamente se effettivamente utilizzate all'interno dell'HTML; deducendo -quindi- erroneamente che usarle con un @apply non andasse ad influire sull'inclusione delle stesse nel bundle finale...

Sotto questo punto di vista -lo ammetto- un po' mi delude...
Farò delle verifiche -comunque- in tal senso... Mi sembra strano!

My bad! 😅

---

C'è poco da girarci attorno; se stanno così le cose, non ha senso -quindi- né usare @apply né rimuovere Tailwind...
Farò un rollback delle mie modifiche, per quanto riguarda lo stile! 😉

Tutti d'accordo?

[sariodesign]

Lasciando Tailwind possiamo sfruttare tutta la libreria di componenti di NuxtUI
In file css generato dalla build importa solo le utility-class utilizzate
Al limiti se su qualche componente particolare occorre aggiungere dello stile facciamo un selettore specifico.

Lascerei Tailwind, aspettiamo gli altri che dicono, così possiamo andare avanti, almeno iniziato a creare una "pagina di atterraggio"

[sariodesign]

Appena fatto il rollback, possiamo chiudere questa PR?
Unica cosa forse nasconderei le voci di menù finché non avremo le altre pagine, che ne dite?

[Byloth]

Per la cronaca: ho fatto il test indicato e ho scoperchiato il vaso di pandora. 🥲

Il purge di Tailwind con NuxtUI non esiste, al momento...
La semplice inclusione di NuxtUI in un progetto fa "zompare" il peso di ogni pagina presente nel bundle finale a oltre 200KB.

Qui la Issue aperta che descrive il problema: nuxt/ui#877

In soldoni, qualunque classe di Tailwind -dalla prima all'ultima- viene inclusa nel bundle (a prescidendere che venga usata o meno).
Inutile -aggiungerei- incrementare ulteriormente il peso del bundle finale con altre classi CSS custom; il rollback è necessario.

---

In ogni caso, la documentazione di Tailwind v2 descrive come vada alla ricerca delle classi nei file: https://v2.tailwindcss.com/docs/optimizing-for-production#writing-purgeable-html

Ergo...
Sì; sarebbero state selezionate anche se non -effettivamente- utilizzate da nessuno... Stupido ma estremamente funzionale! 🤯

(Funzionerà allo stesso modo anche la versione v3 attuale?) 🤔

[Byloth]

Oggi mi son trovato ad approfondire questo discorso...
Ero curioso e volevo, a tutti i costi, riuscire a configurare Tailwind CSS affiché andasse a escludere le classi citate negli @apply.

Sono fortemente convinto che, dei 4 punti elencati a sfavore dell'uso esclusivo di @apply, solo il quarto costituisce un vero e proprio contro: «Your CSS bundle will be bigger»; gli altri 3 -semplicemente- denotano superficialità e non si applicano nel contesto delle applicazioni Vue / Nuxt.

---

Detto questo...
Mi son messo al lavoro per capire come risolvere quest'ultimo problema e consentire effettivamente di usufruire della sola sintassi degli @apply senza alcun downside. Non ho dovuto far molto.

Per questo progetto di esempio ho usato DaisyUI e, una volta seguite le configurazioni iniziali, ho subito provato ad utilizzare una utility random con l'@apply, ho buildato il progetto e ho fatto partire l'esecuzione del server in modalità production.

Fatto. Nothing more; nothing less.
Ovviamente ho fatto anche altre prove di rito e combinazioni di esse: solo utility inline, solo @apply, un misto tra i due utilizzi, usi differenti in componenti diversi, ecc...

---

Il risultato è che Tailwind CSS esclude automaticamente la sezione <style> dei file *.vue dalla sua selezione, non riportando -quindi- le classi eventualmente utilizzate. Per onestà intellettuale, sottolineo che non ho verificato -nel dettaglio- se sia effettivamente merito suo oppure se è merito di Vite, che evita di "passare" queste sezioni a Tailwind... Sinceramente, non ne ho idea e poco mi interessa.

Rimane il fatto che -in fin dei conti- Tailwind CSS rimane intelligente come pensavo fosse...
Decade -quindi- anche il quarto punto a sfavore e, salvo nelle applicazioni con Nuxt UI (almeno per ora), posso tornare in maniera serena ad utilizzare il mio @apply senza alcun problema.

Vi auguro possiate fare lo stesso, nei vostri progetti. 🙃