nextui-org / tailwind-variants

🦄 Tailwindcss first-class variant API
https://tailwind-variants.org
MIT License
2.42k stars 70 forks source link

Mismatched variant nesting generates [object Object] in class #165

Open Cael6 opened 9 months ago

Cael6 commented 9 months ago

Describe the bug When using the extend capabilities, if a variation's value does not match the shape of the extended tv result, it will add [object Object] to the class list rather than calculate the value.

For example:


const styles = tv({
  slots: {
    base: "button",
    other: "other",
  },
  variants: {
    variation: {
      blue: {
        base: "blue",
        other: "other-blue",
      },
    },
  },
});

const extendedStyles = tv({
  extend: styles,
  variants: {
    variation: {
      blue: "extended-blue",
    },
  },
});

styles uses an object to apply variations to variation, but extendedStyles uses a string to apply to just the base.

To Reproduce Steps to reproduce the behavior:

  1. Go to codesandbox example
  2. Inspect Button's class

Expected behavior I expect that both blue and extended-blue are applied to Button's class.

Screenshots image

Desktop (please complete the following information):

Additional context I'm using TypeScript 5.3.3, but on previous versions of TypeScript I believe it would simply omit [object Object] instead of adding in the desired class.

thefalked commented 8 months ago

For me it would make sense to use like this:

const styles = tv({
  slots: {
    base: "button",
    other: "other",
  },
  variants: {
    variation: {
      blue: {
        base: "blue",
        other: "other-blue",
      },
    },
  },
});

const extendedStyles = tv({
  extend: styles,
  variants: {
    variation: {
      blue: {
        base: "extended-blue",
      },
    },
  },
});

or if you want to add the blue: "extended-blue" it would apply to all slots, not just the base one.

keep in mind that base is the name of the slot not the "base" for all slots.

Cael6 commented 5 months ago

Yes, it would work if you matched the structure between styles and extendedStyles, but it should also work with my example as well.

Consider a case where styles is defined in a library and extendedStyles is defined in an application using that library. The types allow you to define extendedStyles as I did in the example, so it ends up not working as expected because the original blue class from styles does not get applied.

It is a very difficult bug to track down if you're not aware of the problem.