Allow passing functions (or regex) for matching compound variants?

[sigtm]

First off, thanks for this! I've been writing similar utilities myself, but never quite landed on an API I liked. So far I'm enjoying the simplicity of this one.

Now maybe I'm just missing something obvious, but I can't quite figure out how to solve this use case. Say I have a button component with these properties:

1. Shape: default / square / rounded / circle
2. Size: xs /  sm /  md /  lg

If the shape is rounded or circle, I want to apply rounded-full. But otherwise, I need separate border radiuses for the two smallest and two biggest sizes.

Is there a way to do that with compound variants, without creating one for every possible combination of shape and size? What I was hoping to do was something like:

variants: {
  shape: {
    default: '',
    round: 'rounded-full,
    circle: 'rounded-full',
    square: '',
  },
  size: {
    xs: 'h-xs',
    sm: 'h-sm',
    md: 'h-md',
    lg: 'h-lg',
  },
},
compoundVariants: [
  {
    size: (v) => ['xs', 'sm'].includes(v),
    shape: (v) => ['default', 'square'].includes(v),
    class: 'rounded-sm',
  },
  {
    size: (v) => ['md', 'lg'].includes(v),
    shape: (v) => ['default', 'square'].includes(v),
    class: 'rounded',
  },
],

I hope that makes sense. The same thing would apply to things like the width as well, where the square/circle buttons need an explicit width for each size.

Or is there a smarter way to handle these types of compound variants?

[joe-bell]

Neat idea! Maybe we could just allow arrays within compoundVariant options for that purpose?

i.e. any variants that match either get the additional class?

compoundVariants: [
  {
    size: ['md', 'lg'],
    shape: ['default', 'square'],
    class: 'rounded',
  },
]

Could be a little fiddly to understand though, and it may also increase the bundle size 🤔

[JeroenReumkens]

I would love this approach. Especially with Tailwind you're just adding classes and you're dependent on the order it ends up in the final bundle. Meaning that if you for example want to override a padding class, you'd rather try to NOT have 2 px-... classes. And in order to prevent that, you might need to add a few more compound variants.

In my opinion it would be super cool if we could next to the array option also add !md as an option, where you could pretty easy create a variant that applies to all sizes, except the md size. I get that might increase the bundle size again, but I do think it will make the implementation in the end even more useful, since you might need to write less variants (which the array option would also have as a result of course 🔥 ).

[JeroenReumkens]

Hey @joe-bell Since I was personally looking forward to this being added, I just took some time to actually create a PR for this 😂 Looking forward to hear what you think about it 🙏

#66

[sigtm]

That looks pretty clean to me at least 👍 I actually ended up whipping up a similar home grown utility that accepts regexes and functions. Partially because with arrays, it may be ambiguous whether it needs all of them to match, or just any of them.

In your example, it basically uses && at the top level (size and shape), but || for the arrays (md or lg).

So personally, I found this more explicit:

{
  size: /md|lg/,
  shape: /default|square/,
  classes: 'rounded-md',
},

A bit nerdier of course 🤓 For reference, here's the bit that adds compound classes in my version:

// Add compound variants to `res`
compound.forEach((def) => {
  const { className, ...rest } = def;

  if (className && Object.keys(rest).every((key) => {
    const propValue = props[key] || defaults[key];
    const matchValue = rest[key];

    if (typeof matchValue === 'function') {
      return matchValue(propValue);
    }
    if (matchValue instanceof RegExp) {
      return matchValue.test(propValue);
    }
    if (typeof matchValue === 'boolean') {
      return Boolean(matchValue) === Boolean(propValue);
    }
    return matchValue === propValue;
  })) {
    res += ` ${className}`;
  }
});

[joe-bell]

Unfortunately, I don’t think this will work with Tailwind’s JIT engine — which needs all classes to be strings

[sigtm]

In practice I haven't needed the boolean coercion to be fair, since I can just use functions for that. And I've barely used functions, but I liked having the option so I can always just pass a component's props straight in and do more complex checks directly in the class composer.

[joe-bell]

Shipped a workaround in #76