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

[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.

[SergeITinc]

Hey @dcastil! 👋

Thank you for your detailed explanation regarding the object syntax and its impact on readability and cognitive load. I understand your perspective and appreciate the thought process behind preferring the && syntax.

@MrEfrem
However, I believe there's a middle ground that maintains readability without introducing the runtime overhead of supporting object syntax.
Here's my proposal using array notation with twMerge:

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

This approach keeps the classes visible upfront, making it easier to see which Tailwind classes are being applied, while still conditionally applying classes based on the state. It avoids the cognitive load of jumping back and forth between conditions and class names.

I think this strikes a good balance between readability and performance, and it doesn't require adding support for object syntax.

Looking forward to hearing your thoughts!

Best regards,
Serge

[dcastil]

Hey @SergeITinc! 👋

The array syntax already works in tailwind-merge! It's supported since v1.6.0.

[SergeITinc]

@dcastil

Thank you for the quick response!

I apologize if my previous message was unclear. I wasn't suggesting creating a new approach or introducing object syntax. My intention was to demonstrate how we can effectively use the existing array notation in tailwind-merge to handle conditional class names.

This approach leverages the array syntax to conditionally apply classes without adding any new features or syntaxes. It keeps the code clean and readable while utilizing the capabilities of tailwind-merge.

My goal was to show different ways to use the existing functionality for anyone reading the discussion.

Thank you for your understanding!

Best regards,
@SergeITinc

[dcastil]

Ah got it. 🙂