Support more argument types as classNames does

[meness]

classnames supports different arguments, including conditional strings. It would be good to have that in this package too.

className={twMerge('p-4', {'p-0': yes, 'p-9': no})}

Here is my workaround:

import cn, { Argument } from 'classnames';
import { twMerge } from 'tailwind-merge';

/**
 * Works just like `twMerge`, but uses built-in `classNames`.
 *
 * @param classNames
 * @returns
 */
export function cnMerge(...classNames: Argument[]) {
  return twMerge(cn(classNames));
}

Does my workaround effect the cache behavior?

[dcastil]

Hey @meness! 👋

Yeah I thought about it many times but inlining classnames or clsx would be the same as your approach in the workaround. The only difference is that people who don't want the bundle size increase of the classnames package would be forced to use it because it is included in the package. The caching behavior won't get affected by your workaround.

Is there a reason why you'd prefer to have the argument types of classnames in tailwind-merge instead of using the workaround? Are you using Tailwind CSS with the default config?

But I'll think about it, maybe it I should really include it.

[charkour]

Totally agree, people might not want to use classnames or clsx so I'd suggest tw merge to remain unopinionated.

[dcastil]

Actually tailwind-merge is somewhere in the middle, replicating a part of clsx. I also thought whether it should move to accept a single string only, making prepending with clsx or classnames necessary or fully inlining clsx/classnames. If a codebase is using a library like that already, it might even decrease bundle size because I could remove the code to join the arguments.

[dcastil]

The more I'm thinking about this, the more I think I should include clsx in tailwind-merge. My reasons:

1. clsx (or its pendant classnames) is probably already included in most projects using tailwind-merge. I have copied parts of clsx and inlined it in tailwind-merge to join strings, so adding it would have almost no impact on bundle size nor runtime performance.

2. I find the pattern of nested conditions with arrays in clsx really nice and often miss it in tailwind-merge. Basically this:

   clsx('…', someBool && ['…', anotherBool && '…'])

3. Prepending twMerge with clsx myself is not so nice DX-wise, even when using tailwind-merge with a custom config. It can even lead to anti-patterns.

   // This feels a little weird
   const twMergeInternal = extendTailwindMerge(…)
   export const twMerge = (...args) => twMergeInternal(clsx(args))
   
   // I really hope no one is doing this!
   export const twMerge = (...args) => extendTailwindMerge(…)(clsx(dontDoThis!))

I think I'll give it a shot. And if it turns out not to be a good idea, I think tailwind-merge should go into the opposite direction in a v2 update and only accept a single string as argument. This way the user could choose their own string-joining lib and tailwind-merge would leave the weird middle ground it is on right now.

[dcastil]

Issue → #124

[dcastil]

@gabrielmlinassi @charkour Is there a reason why you think it's better to keep the workaround besides what @charkour mentioned already? I'd be interested in the counterarguments to adding clsx to tailwind-merge.

I'm also thinking about the option to only add array support to tailwind-merge and not the full clsx functionality because I think the object syntax is inferior and shouldn't be used. I'm not fully convinced of which route to go yet because that would make tailwind-merge opinionated.

To why I don't like the object syntax, here is an explanation I wrote to a coworker yesterday:

I think it's better not to use the object notation for classNames in clsx. When I parse classNames, I'm always interested in the condition first to know whether I even need to think about the classes or not and only afterwards I want to deal with the actual classes. The object notation turns that around and increases the cognitive load because I need to skip the classNames string to get to the condition and then return back to the string again. Also, when object keys don't have quotes around them, it's easy to miss them since I focus on the color of string literals during parsing.

[charkour]

Your email to a coworker describes the same reason why I dislike the object syntax.

Since you're the library maintainer, @dcastil, I trust your judgment and decision regarding where you want to take tailwind-merge. To expand on the idea of keeping tw-merge unopinionated is to add a "Common Pattern" or "Recipies" to the readme similar to other utility libraries (zustand's comes to mind). For tw-merge, the readme could be updated to have a section on extending tw-merge's class name behavior with classNames or clsx which is what @gabrielmlinassi suggested. I see this workaround effectively as middleware for tailwind-merge.

Benefits to keeping tw-merge unopinionated are less complexity for the library, smaller bundle size, and more extensibility for users of the library.

I hope this is helpful! Again, do what you would think is best. Thanks.

[mreduar]

Greetings, I happen to have the problem with this array thing, I thought twMerge would be able to handle the cases when there is an array involved as well as objects and flat classes. I was going to open an issue, but first I decided to do some digging since I figured it was a known common problem.
For my part I use vue, and in vue we use a lot of object syntax. Even when you go to the binding classes documentation the first examples you encounter are objects

I think it would be a good idea to incorporate support for arrays, objects and flat classes all at the same time. The object syntax on my side is not confused by the fact that the condition is at the end or not at the beginning.

I'd rather use { 'bg-indigo-600' : active } than active ? 'bg-indigo-600' : '' for example.

Btw, thanks for suggesting clsx, I think I will solve the problems I have for now with that.

[dcastil]

Thanks for your input @mreduar! You can read a long explanation of my reasoning not to implement the object syntax in #137 (comment). For now, if you want to use the object syntax, you can use clsx:

import { twMerge as twMergeOriginal } from 'tailwind-merge'
export const twMerge = (...args) => twMergeOriginal(clsx(args))