Undvik klasskonflikter med tailwind-merge

Tailwinds verktygsklasser anger enskilda CSS-egenskaper. När två klasser riktar sig mot samma egenskap — till exempel p-4 och p-8, eller text-blue-500 och text-red-500 — hamnar båda i elementets klasslista. Webbläsaren löser konflikten med hjälp av CSS-kaskadordningen: den verktygsklass som genererades senare i Tailwinds stilmall vinner, oavsett ordningen i HTML-koden. Utan tailwind-merge blir det därför oförutsägbart att åsidosätta stilar från överordnade komponenter.

tailwind-merge är ett verktyg som körs vid körning och analyserar en klasssträng för att ta bort motstridiga Tailwind-klasser. Endast den sista klassen i varje konfliktgrupp behålls. Verktyget har en intern mappning över vilka Tailwind-verktygsklasser som står i konflikt med varandra — till exempel att p-4 och p-8 båda anger utfyllnad, eller att font-bold och font-medium båda anger font-weight. Den sista klassen i indatasträngen vinner alltid.

Installera tailwind-merge som ett produktionsberoende, inte enbart som ett utvecklingsberoende, eftersom det körs vid körning. Importera twMerge och omslut alla klasssträngar som kan innehålla konflikter. Funktionen tar emot flera argument och slår samman dem alla, ungefär som clsx tar emot flera argument — vilket gör det enkelt att införa i befintlig kod.

tailwind-merge förstår hela Tailwinds taxonomi av verktygsklasser. Det vet att px-4 anger horisontell utfyllnad medan py-2 anger vertikal utfyllnad, så de står inte i konflikt. Det vet att shadow-md och shadow-lg båda anger egenskapen box-shadow och därför står i konflikt. Det hanterar också varianter som hover:bg-blue-500 och hover:bg-red-500 som en separat konfliktgrupp från deras motsvarigheter utan varianter.

Det vanliga mönstret i React-/Next.js-projekt är att kombinera clsx och twMerge i en enda hjälpfunktion, cn(). clsx hanterar villkorslogik för klasser och filtrerar bort falska värden; därefter löser twMerge eventuella konflikter i den resulterande strängen. Definiera detta en gång i Er utils-fil och använd det överallt — det är den metod som används av shadcn/ui och de flesta moderna Tailwind-komponentbibliotek.

Det främsta användningsområdet för tailwind-merge i React-komponenter är att möjliggöra säkra åsidosättningar via className-propen. När en komponent har standardstilar och den som anropar komponenten skickar in ytterligare eller ersättande klasser via propen className, ser twMerge till att anroparens avsikt respekteras. Då blir komponenterna verkligen anpassningsbara, utan att användarna behöver kämpa mot CSS-specificitet eller använda !important.

tailwind-merge hanterar även klasser med godtyckliga värden som använder Tailwinds hakparentesnotation. Det identifierar korrekt att p-[10px] står i konflikt med p-4 och att w-[300px] står i konflikt med w-full. Detta är viktigt eftersom godtyckliga värden är vanliga när Ni utformar komponenter som behöver exakta mått som inte finns i standardskalan.

Som standard känner tailwind-merge endast till Tailwinds standardverktygsklasser. Om Ni har lagt till anpassade verktygsklasser via plugin-program eller konfigurationen känner twMerge inte till att de står i konflikt med relaterade standardklasser. Använd extendTailwindMerge() för att lära twMerge om Era anpassade klasser, så att konfliktlösningen fungerar korrekt för den utökade uppsättningen verktygsklasser.

tailwind-merge tolkar och löser klasssträngar vid körning i webbläsaren. För de flesta program går detta omärkbart snabbt. Komponenter som renderar tusentals instanser, till exempel virtuella listor eller tabellceller, kan dock ha nytta av att cacha den lösta klasssträngen. tailwind-merge tillhandahåller fabriken createTailwindMerge(), som möjliggör en anpassad cacheadapter. För de flesta appar räcker standardcachen, som använder en LRU internt.

Det finns några specialfall i tailwind-merge som Ni bör känna till. Det hanterar inte CSS Modules-klasser — endast namn på Tailwinds verktygsklasser. Om en klasssträng innehåller klasser som inte kommer från Tailwind, till exempel anpassade BEM-klasser, skickar twMerge vidare dessa utan ändringar. Vissa plugin-genererade verktygsklasser kanske inte känns igen utan att merge-konfigurationen utökas. Slutligen arbetar twMerge med klasssträngen, inte med den renderade CSS-koden, och kan därför inte lösa konflikter som orsakas av CSS-kaskaden utanför Tailwinds verktygsklasser.

När Ni skriver enhetstester för komponenter som använder cn() bör Ni testa den faktiska klasssträngen som skapas, för att verifiera att konflikter löses korrekt. Detta är särskilt värdefullt för komponentbibliotek där användare måste kunna åsidosätta standardvärden på ett tillförlitligt sätt. Snapshot-tester av className-resultat säkerställer att framtida omstruktureringar inte råkar förstöra beteendet för åsidosättningar.

I den här lektionen har Ni lärt Er att tailwind-merge löser konflikter mellan Tailwinds verktygsklasser genom att endast behålla den sista klassen i varje konfliktgrupp, att cn()-hjälpfunktionen kombinerar clsx och twMerge för villkorsstyrd och konfliktfri klasshantering samt att extendTailwindMerge() lär biblioteket om anpassade plugin-klasser. Härnäst utforskar vi Headless UI och hur det integreras med Tailwind för tillgängliga komponenter.