Unngå klassekonflikter med tailwind-merge

Tailwind-verktøyklasser angir individuelle CSS-egenskaper. Når to klasser målretter den samme egenskapen — for eksempel p-4 og p-8, eller text-blue-500 og text-red-500 — ender begge opp i elementets klasseliste. Nettleseren løser konflikten ved hjelp av CSS-kaskaderekkefølgen: verktøyklassen som ble generert sist i Tailwind-stilarket, vinner, uavhengig av rekkefølgen i HTML-en. Uten tailwind-merge blir det derfor uforutsigbart å overstyre stiler fra overordnede komponenter.

tailwind-merge er et verktøy som kjøres ved kjøring, og som analyserer en klassestreng og fjerner motstridende Tailwind-klasser. Bare den siste klassen fra hver konfliktgruppe beholdes. Verktøyet har en intern oversikt over hvilke Tailwind-verktøyklasser som er i konflikt med hverandre — for eksempel at p-4 og p-8 begge angir padding, eller at font-bold og font-medium begge angir font-weight. Den siste klassen i inndatastrengen vinner alltid.

Installer tailwind-merge som en produksjonsavhengighet (ikke bare for utvikling, siden den kjører ved kjøring). Importer twMerge og pakk inn alle klassestrenger som kan inneholde konflikter. Funksjonen tar imot flere argumenter og slår dem sammen, på samme måte som clsx tar imot flere argumenter — noe som gjør det enkelt å ta den i bruk i eksisterende kode.

tailwind-merge forstår hele Tailwinds taksonomi for verktøyklasser. Den vet at px-4 angir horisontal padding, mens py-2 angir vertikal padding, og at de derfor ikke er i konflikt. Den vet at shadow-md og shadow-lg begge angir egenskapen box-shadow, og derfor er i konflikt. Den håndterer også varianter som hover:bg-blue-500 og hover:bg-red-500 som en separat konfliktgruppe fra de tilsvarende klassene uten variant.

Det vanlige mønsteret i React-/Next.js-prosjekter er å kombinere clsx og twMerge i én cn()-hjelpefunksjon. clsx håndterer betinget klasselogikk og filtrerer bort falske verdier, mens twMerge deretter løser eventuelle konflikter i den resulterende strengen. Definer dette én gang i utils-filen, og bruk det overalt — dette er fremgangsmåten som brukes av shadcn/ui og de fleste moderne Tailwind-komponentbiblioteker.

Det viktigste bruksområdet for tailwind-merge i React-komponenter er å muliggjøre sikre overstyringer med className-propen. Når en komponent har standardstiler og den som kaller komponenten, oppgir ekstra eller erstattende klasser via className-propen, sørger twMerge for at hensikten til den som kaller komponenten, blir respektert. Dermed blir komponentene reelt tilpasningsbare uten at brukerne må kjempe mot CSS-spesifisitet eller bruke !important.

tailwind-merge håndterer også klasser med arbitrære verdier ved hjelp av Tailwinds klammeparentesnotasjon. Den identifiserer korrekt at p-[10px] er i konflikt med p-4, og at w-[300px] er i konflikt med w-full. Dette er viktig fordi arbitrære verdier er vanlige når man utformer komponenter som trenger nøyaktige mål som ikke finnes i standardskalaen.

Som standard kjenner tailwind-merge bare til Tailwinds innebygde verktøyklasser. Hvis De har lagt til egendefinerte verktøyklasser via programtillegg eller konfigurasjonen, vet ikke twMerge at de er i konflikt med relaterte standardklasser. Bruk extendTailwindMerge() til å lære twMerge om de egendefinerte klassene, slik at konfliktløsningen fungerer korrekt for det utvidede settet med verktøyklasser.

tailwind-merge analyserer og løser klassestrenger ved kjøring i nettleseren. For de fleste applikasjoner går dette så raskt at det knapt merkes. Komponenter som gjengir tusenvis av instanser (for eksempel virtuelle lister eller tabellceller), kan imidlertid ha nytte av å bufre den løste klassestrengen. tailwind-merge tilbyr en createTailwindMerge()-fabrikk som muliggjør en egendefinert cache-adapter. For de fleste apper er standardbufferet, som internt bruker LRU, tilstrekkelig.

tailwind-merge har noen kanttilfeller De bør kjenne til. Den håndterer ikke CSS Modules-klasser — bare navn på Tailwind-verktøyklasser. Hvis en klassestreng inneholder klasser som ikke er fra Tailwind (for eksempel egendefinerte BEM-klasser), lar twMerge dem passere uendret. Enkelte verktøyklasser som genereres av programtillegg, blir heller ikke gjenkjent uten at sammenslåingskonfigurasjonen utvides. Til slutt opererer twMerge på klassestrengen, ikke på den gjengitte CSS-en, så den kan ikke løse konflikter som skyldes CSS-kaskaden utover Tailwind-verktøyklasser.

Når De skriver enhetstester for komponenter som bruker cn(), bør De teste det faktiske resultatet av klassestrengen for å kontrollere at konflikter løses korrekt. Dette er særlig verdifullt for komponentbiblioteker, der brukerne må kunne overstyre standardverdier på en pålitelig måte. Snapshot-tester av className-resultater sikrer at fremtidige omstruktureringer ikke utilsiktet ødelegger overstyringsfunksjonen.

I denne leksjonen lærte De at tailwind-merge løser konflikter mellom Tailwind-verktøyklasser ved å beholde bare den siste klassen fra hver konfliktgruppe, at cn()-hjelpefunksjonen kombinerer clsx og twMerge for betinget og konfliktfri klassehåndtering, og at extendTailwindMerge() lærer biblioteket om egendefinerte programtilleggsklasser. Deretter skal vi se på Headless UI og hvordan det integreres med Tailwind for tilgjengelige komponenter.