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

[MrEfrem]

Thanls @dcastil for this great explanation.

But on my opinion this approach looks better

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 py-4 mb-10 rounded-lg',
    {
        '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
    }
)

than this

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 py-4 mb-10 rounded-lg',
    (!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'
)

because you see your classes first and you usually look at Figma, your browser or something more where you can take your design. So for you it's no
less important to know which TW classes you need to add, change, delete.
But when you see mix classes with conditions in the second approach it's really more difficult to talk about design.
Finally, I think should be implemented both approaches because for every of them there are pros and cons.

[dcastil]

Thanks for your point of view on this! I'll think about this. 🤔

You can also make twMerge accept objects by wrapping it with your own function for the time being.

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

export function twMerge(...args) {
    return twMergeOriginal(clsx(args))
}

[marcelo-mason]

Your open-minded reply was refreshing. Thanks for providing a workaround. I prefer a mixture where I use object syntax to group related conditions together.