Tag: css, tailwindcss, frontend, styling, utility-first, responsive
Livello: intermedio
TL;DR: Framework CSS utility-first per comporre interfacce direttamente nel markup con generazione Just-in-Time (JIT) e purging automatico delle classi inutilizzate.
Approccio utility-first: composizione dello stile tramite classi atomiche a scopo singolo direttamente nel markup HTML o JSX.
Compilatore Just-in-Time (JIT): genera su richiesta solo le regole CSS effettivamente referenziate nei file sorgente configurati.
Design system configurabile: palette colori, spaziature, breakpoint e font centralizzati nel file tailwind.config.js o via @theme in v4.
Modifier e varianti: gestione di stati come hover, focus, active e dark mode anteponendo il prefisso corrispondente alla classe.
Mobile-first responsive design: le classi base si applicano a schermi piccoli, i breakpoint (sm:, md:, lg:) scalano verso l'alto.
Arbitrary values: supporto a valori custom immediati tramite parentesi quadre (es. w-[350px], top-[17px]).
Separazione logica senza contest switching: evita l'invenzione di nomi di classi BEM e riduce la crescita del bundle CSS.
Q: Perché preferire Tailwind CSS rispetto ai CSS tradizionali o ai CSS Modules?R: Perché elimina il context-switching continuo tra markup e fogli di stile, blocca la crescita infinita del bundle CSS tramite JIT e impone un design system coerente senza dover inventare convenzioni di nomi arbitrarie.
Q: Come risolvi il conflitto o l'override di classi condizionali in componenti React?R: Utilizzo la combinazione di clsx (o classnames) insieme a tailwind-merge tramite una funzione helper tipo cn(), garantendo che l'ultima classe passata sovrascriva correttamente le classi di default senza problemi di specificità CSS.
Q: Che differenza c'è tra usare @apply e mantenere le classi inline?R: Mantengo le classi inline per beneficiare della manutenibilità locale e dell'eliminazione del codice morto; riservo @apply strettamente a reset globali o componenti non controllabili dal framework per evitare di ricadere nei problemi del CSS classico.
Stringhe dinamiche interpolate (es. text-${color}-500): lo scanner statico non le trova e non genera il CSS a build time.
Abuso di @apply: ricrea i problemi di specificità e accoppiamento del CSS tradizionale annullando i vantaggi dell'utility-first.
Conflitti di specificità CSS nell'unione di classi: unire stringhe senza tailwind-merge non garantisce la precedenza dell'ultima classe utility.
Dimenticare di configurare il percorso dei file nel content: le classi presenti nei file non mappati vengono eliminate dalla build finale.
```npm install -D tailwindcss postcss autoprefixer
npx tailwindcss init -p
// tailwind.config.js
/** @type {import('tailwindcss').Config} */
module.exports = {
content: [
"./src/**/*.{js,jsx,ts,tsx}",
"./index.html",
],
theme: {
extend: {
colors: {
brand: {
50: '#f0fdf4',
500: '#22c55e',
900: '#14532d',
},
},
},
},
plugins: [],
}
// Helper per unione sicura di classi Tailwind (evita collisioni di specificità)
import { clsx, type ClassValue } from 'clsx';
import { twMerge } from 'tailwind-merge';
export function cn(...inputs: ClassValue[]): string {
return twMerge(clsx(inputs));
}
<!-- Componente card responsive con stati hover e dark mode -->
<div class="flex flex-col md:flex-row items-center gap-4 p-6 bg-white dark:bg-slate-800 rounded-xl shadow-md hover:shadow-lg transition-shadow">
<img class="w-16 h-16 rounded-full object-cover" src="/avatar.jpg" alt="Profile" />
<div class="text-center md:text-left">
<h3 class="text-lg font-bold text-slate-900 dark:text-white">Umberto</h3>
<p class="text-sm text-slate-500 dark:text-slate-400">Software Engineer</p>
</div>
</div>
```
[ ] Regola di scanning statico delle classi e pattern consentiti con safelist
[ ] Integrazione di clsx + tailwind-merge nei componenti UI riutilizzabili
[ ] Configurazione della variante dark: (strategia media vs selector / class)
[x] Sintassi dei prefissi responsive mobile-first (sm:, md:, lg:, xl:, 2xl:)
[x] Meccanismo JIT e purging delle classi non referenziate