Add Objects (variadic) syntax (similar to classnames, clxs)

[MrEfrem]

classnames, clxs libraries support very useful object syntax to conditionally apply rules.
Would it be possible to implement the same syntax here? Then we will be able to use only one library for class names managing.

// Objects (variadic)
clsx({ foo:true }, { bar:false }, null, { '--foobar':'hello' });
//=> 'foo --foobar'

[dcastil]

Hey @MrEfrem! 👋

I didn't implement the object syntax because I think it's easier to read code using the && syntax instead. Therefore I don't want to add the runtime overhead for object syntax support.

Long explanation

When I read a collection of conditionally applied classes, 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 string with all the classes to get to the condition and then return back to the string again.

Let me show you what I mean on a real example (formatted with Prettier), first using an object.

clsx({
    'px-8 sticky grid items-center grid-flow-col grid-cols-1 transition cursor-pointer bg-clip-padding border-y border-white hover:bg-grey-700-opaque-5':
        true,
    'bg-white': !transparentWhenFloaty || position !== Position.Floaty,
    invisible: isInvisible,
    // Fixes sticky position bug in Chrome. More info: <private link>
    'before:absolute before:left-0 before:-top-px before:w-full before:h-px before:bg-white':
        position === Position.StickyTop,
    'before:absolute before:left-0 before:-bottom-px before:w-full before:h-px before:bg-white':
        position === Position.StickyBottom,
    'border-t-grey-700/10': position === Position.StickyBottom,
    'border-b-grey-700/10': position !== Position.StickyBottom,
})

Let's say I need to fix something at this DOM node when the component is in the StickyBottom position and want to check all the classes being applied in this state. Here are some aspects I don't like about this syntax:

1. While reading the code, I constantly need to jump back and forth, skipping the classes string, checking the condition and going back to the classes string to acknowledge the classes as being applied.
2. Because the class strings have very different lengths, every condition is in a different place which makes it harder to find quickly.
3. It's easy to miss the invisible class because it doesn't have quotes around it and therefore editors apply different styling to it. E.g. I'm used to my editor displaying strings in blue and focus on that color, but the invisible class is rendered in white.

Now let's take a look at the same code using the logical && operator instead. This is also the original code.

clsx(
    'px-8 sticky grid items-center grid-flow-col grid-cols-1 transition cursor-pointer bg-clip-padding border-y border-white hover:bg-grey-700-opaque-5',
    (!transparentWhenFloaty || position !== Position.Floaty) && 'bg-white',
    isInvisible && 'invisible',
    // Fixes sticky position bug in Chrome. More info: <private link>
    position === Position.StickyTop &&
        'before:absolute before:left-0 before:-top-px before:w-full before:h-px before:bg-white',
    position === Position.StickyBottom &&
        'before:absolute before:left-0 before:-bottom-px before:w-full before:h-px before:bg-white',
    position === Position.StickyBottom ? 'border-t-grey-700/10' : 'border-b-grey-700/10'
)

Thinking about the three points mentioned:

1. I don't need to jump back and forth in code anymore when reading it. I can read the condition and when it isn't interesting to me, I skip the following string and continue to the next condition.
2. Every new line starts with a condition which makes it easier for me to find the ones I'm interested in.
3. All class strings, including the one containing invisible have the same styling in my editor which makes it faster to find them.

Conclusion

I think the object syntax shouldn't be used to apply Tailwind classes conditionally and therefore I didn't add support for it in tailwind-merge. Because of this I built a join twJoin function which is essentially a copy of clsx but without support for objects which makes it even faster than clsx.

But if you have a use case where you think the object syntax makes more sense than &&, I'm interested in hearing about it! There's always the chance that I missed something.

---

Related: #121 (reply in thread), #124

[alexchexes]

Yeah, I understand, no arguing. It's your project and your decision. Anyway, for those of us who are used to object syntax and comfortable with it, we can indeed wrap twMerge in a helper like const twMergeX = (...args) => twMerge(clsx(args))

[GiantRobots]

Hi there! I understand the style preference but it unfortunately conflicts with Svelte5's usage of cslx. It would be really convenient to just be able to do....

<script lang="ts">
	import { twMerge } from 'tailwind-merge';
	import type { ClassValue } from 'svelte/elements';
	import type { Snippet } from 'svelte';

	let { class: className, children }: { class: ClassValue; children: Snippet } =
		$props();
</script>

<button class={twMerge(className)}>
	{@render children?.()}
</button>

But we get the type error of

Type 'ClassValue' is not assignable to type 'ClassNameValue'.
  Type 'ClassArray' is not assignable to type 'ClassNameValue'.
    Type 'ClassValue[]' is not assignable to type 'ClassNameArray'.
      Type 'ClassValue' is not assignable to type 'ClassNameValue'.
        Type 'number' is not assignable to type 'ClassNameValue'.

To fix this I will likely do what @alexchexes recommended which is add cslx to our twMerge for the functionality but it's unfortunate to have to have our own implementation when it feels like it should be a slam dunk to just use twMerge directly on classNames.

[dcastil]

@GiantRobots you can create a file with your own twMerge which allows these types.

Either

import { twMerge as twMergeOriginal } from 'tailwind-merge'

// Just wing it and promise not to use objects as inputs
export const twMerge = twMergeOriginal as (...args: any[]) => string

or

import { twMerge as twMergeOriginal } from 'tailwind-merge'
import { clsx } from 'clsx'

export function twMerge(...args: any[]) {
    return twMergeOriginal(clsx(args))
}

[GiantRobots]

Yeah I'll be doing that in our code but wanted to let you/others know about that piece of interop weirdness as a result of this decision.

[armchair-traveller]

Svelte again. I also avoid object syntax, but honestly these types feel more trouble than they’re worth. I don’t want to install clsx just for its types when Svelte already pulls it in--that’s duplicate deps for no real benefit. And with tailwind-merge having its own flavor, that’s effectively three copies of the same thing, haha.

The “easy” fixes don’t work with Tailwind Variants because it depends on ClassNameValue from tailwind-merge as a peer dep. For example:

buttonVariants({ className })

className throws similar errors to [@GiantRobots’ issue](#137 (reply in thread)).

Unlike twMerge, which you can patch with a simple declare module/declare const, tv’s types are a web of deep generics and not straightforward to override. I’m sure a TypeScript wizard could prove me wrong, haha...but I’m not eager to wrap tv and ship my own module just to make TS happy.

For now, I’m using the ClassProp type that tailwind-variants exposes and intersecting it onto my props whenever tv is used, not often does a component have need for variants after all.

Not begging for a fix, just adding another perspective.