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

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

[alexchexes]

Hello @dcastil! I just wanted to share a thought about what you said:

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.

I completely agree, and it’s definitely frustrating. However, I always use "quoteProps": "preserve" in my .prettierrc to avoid the unwanted removal of quotes when they’re actually needed. Is there a particular reason why you don’t do the same? Just curious. Thank you for your work!

// .prettierrc.json
{
  "$schema": "https://json.schemastore.org/prettierrc",
  "semi": false,
  "singleQuote": true,
  "printWidth": 100,
  "quoteProps": "preserve", // here it is
}

[dcastil]

@alexchexes oh that's a nice setting, didn't know about it. Might apply this, too. But my point about jumps in reading code still stands.

[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 twMergeO = (...args) => twMerge(clsx(args))