How to get the conflicting classes?

[akinuri]

Does this tool provide a way to get the conflicting classes?

Let's say I'm adding classes to an element dynamically, after the page is rendered. The new classes will conflict with the existing classes. The conflicting classes need to be removed. What kind of approach is suggested in such scenario?

I'd imagine something like this:

element.classList.remove( ...twConflicts(element.className, "new-class-1 new-class-2") )

Currently, I'm handling it like the following, but it doesn't sit well with me. There might be a case where the conflicting classes need to be known.

element.className = twMerge(element.className, "new-class-1 new-class-2");

I'm ignoring any assumtions this tool makes about its usage, if there are any, e.g. a UI framework.

---

Okay, on second thought (in addition to showing how I handle adding new classes), there needs to be a way to get the conflicting classes. If I'm marking an element (with classes), there's a straightforward way to merge and remove the conflicting classes, but to unmark the element, I need to add back the removed classes. There are ways to workaround this issue, but it'd be nice to have a function that just returns the conflicting classes, especially considering the tool must be doing the same operation (finding conflicts) internally.

---

I thought I should include my workaround. I store the conflicting classes when I mark an element. When it's time to unmark it, remove the new classes, and add the conflicting classes back.

function twConflicts(baseClasses, newClasses) {
    return arrayDiff(
        baseClasses.split(" "),
        twMerge(baseClasses, newClasses).split(" "),
    );
}
function arrayDiff(arrayA, arrayB) {
    return arrayA.filter(item => !arrayB.includes(item));
}

[dcastil]

Hey @akinuri! 👋

This is an interesting use case, but also very custom. At the moment, your workaround is indeed the only way to get the removed classes. I use the same approach to mark the removed classes with a red background in https://codesandbox.io/p/sandbox/tailwind-merge-playground-cssr35?file=%2Fsrc%2Findex.ts.

I think it makes sense for tailwind-merge to expose a low-level API to get that info. This will take some time because I'm not sure yet about the best way to provide it, but I created the issue #385 to track that specific feature and collect some input.

In case you need a good solution for this faster, you can fork tailwind-merge and modify it to get this functionality. All the important code for this is in https://github.com/dcastil/tailwind-merge/blob/v2.2.1/src/lib/merge-classlist.ts#L73-L94.

[akinuri]

Hi

What does "custom" mean in this case? My guess is it's about not using a UI framework. Am I right?

I suppose, with UI frameworks, elements get re-rendered with the appropriate (class) changes so the actual element never really gets updated. It's replaced with the updated version. With a setup like this, there's no need to manually remove the new classes and add the old/conflicting ones back to get back to the default/old state. Thus, twMerge is enough on its own.

I have no practical experience with UI frameworks, so my guess might be off.

The workaround I'm using seems to be enough for now. Might consider tweaking the source if I come across further issues.

[dcastil]

What does "custom" mean in this case? My guess is it's about not using a UI framework. Am I right?

With custom I mean that you don't want to just merge Tailwind classes but instead only want to get the conflicting classes. I think not using a UI framework is totally fine and should be supported by tailwind-merge.

I find the code from your second example totally valid.

element.className = twMerge(element.className, "new-class-1 new-class-2");

It's quite similar to how a UI framework like React works, updating properties of nodes that changed between renders.