How to get all variants and it's options?

[syabro]

E.g. I have

export const buttonVariants = cva(['your', 'base', 'classes'], {
  variants: {
    color: {
      primary: 'bg-primary-600 hover:bg-primary-500 text-white',
      dark: 'bg-gray-800 hover:bg-gray-700 text-white',
      light: 'bg-gray-200 hover:bg-gray-300 text-gray-800',
      danger: 'bg-red-600 hover:bg-red-500 text-white',
      gray: 'bg-gray-600 hover:bg-gray-500 text-white',
      info: 'bg-blue-600 hover:bg-blue-500 text-white',
      purple: 'bg-purple-600 hover:bg-purple-500 text-white',
      success: 'bg-green-600 hover:bg-green-500 text-white',
      warning: 'bg-yellow-600 hover:bg-yellow-500 text-white',
    },
    size: {
      xs: 'px-2 py-1',
      sm: 'px-2 py-1',
      md: 'px-2.5 py-1.5',
      lg: 'px-3 py-2',
      xl: 'px-4 py-2',
    },
  },
  defaultVariants: {
    color: 'primary',
    size: 'md',
  },
})

And I want to create a storybook with all options without copypasting them.
How can I extract all colors and sizes?

[syabro]

Ended up writing my own tcva function
Maybe we can add this functionality to the main package?

import { ClassValue, ClassProp, StringToBoolean } from 'class-variance-authority/dist/types'
import { ConfigSchema, ConfigVariants, Config, cva } from 'class-variance-authority'

type TcvaProps<T> = T extends ConfigSchema ? ConfigVariants<T> & ClassProp : ClassProp
type TcvaReturnFunction<T extends ConfigSchema> = {
  (props?: TcvaProps<T> | undefined): string
} & {
  [K in keyof T]: T[K]
}
export declare type TCVA = <T extends ConfigSchema>(
  base?: ClassValue,
  config?: Config<T> | undefined
) => TcvaReturnFunction<T>

export const tcva = <T extends ConfigSchema>(base: ClassValue, config: Config<T>) => {
  const variantsFn: TcvaReturnFunction<T> = cva(base, config) as TcvaReturnFunction<T>
  for (const variant of Object.keys(config.variants!)) {
    ;(variantsFn as any)[variant] = config.variants![variant]
  }
  return variantsFn
}

[switz]

do you have an updated version for the latest cva? seems some of these types are no longer exported

[joe-bell]

It's on my todo list for 1.0!

Thanks for sharing your solution 🙏

[bengry]

I've updated my minor fork to support a more advanced use-case since:

const box = cva({
  variants: {
    shadow: {
      sm: "shadow-sm",
      md: "shadow-md"
    }
  },
  defaultVariants: {
    shadow: "sm"
  }
});

box.variants;
//      ^?
//      { shadow: ReadonlyArray<{ 'sm' | 'md' }> }

This allows using objectKeys(box.variants) to get the names of all variants, while box.variants.shadow is also useful in itself, for things like Storybook's argTypes and args (when using controls that require options).

We've been using this in production for a few months now and find it very useful.

P.S.
All of the above also works (and is typed accordingly) for compose.
Relevant tests were also added to the fork.

Do note that all of this is a fork for cva@beta, not class-variance-authority.

[joe-bell]

Hey @bengry, finally finding some time to come back to this. Really impressed by your .variants feature! Would you be OK for me to take some of this work as inspiration for the official solution? More than happy to provide credit/co-author commits where necessary

[bengry]

@joe-bell What timing. I just published a cva-extended package as a proper fork.

It does a bit more than just the .variants. You can see the changes made to the original package listed here.

We've been using all of these at my day job for the past year or more and it has been working great for us.

Feel free to take any inspiration from it and merge things back to cva. I think we'll still need the fork though, unless all of these features land in cva itself. Credit and co-author commits would be appreciated :)

[joe-bell]

@bengry ha amazing timing, apologies for the massive delay on my end. Congrats on the ship!

Thanks for the overview of changes, I’ll of course make sure you’re credited where credit is due. I’ll keep you posted on where I end up 🤝

Your extended feature list is eerily close to the private brain-dump I’ve been jotting away in for months; I think the only difference is I would’ve opted for _ instead $ for private variants.

I’m still a little torn on required/optional variants as it’s proved fiddly when needing to reference default props in framework components such as React, but maybe this could be solved by exporting a .defaultVariants for those use-cases 🤔

Happy to see that we’re pretty aligned, and excited to hear how your fork continues

[bengry]

@joe-bell all good. Since I forked the package a while ago (~1.0.0.beta.1, over a year ago at this point) we've been working with it, so no worries. It also allowed us to experiment with other changes - like making the props required when no defaultVariants is specified for a given variant, as well as private variants. Both have proved themselves, especially the former.

Thanks for the overview of changes, I’ll of course make sure you’re credited where credit is due. > I’ll keep you posted on where I end up 🤝

Thanks, much appreciated :), and please do - I want to see what ends up being the change and whether or not we need to keep the fork around, or at least how to rebase on top of your work :)

Your extended feature list is eerily close to the private brain-dump I’ve been jotting away in for months; I think the only difference is I would’ve opted for _ instead $ for private variants.

I went with $ since it made things a tiny bit easier to read as object keys IMO, but really - I don't care either way. As long as the ability is there and is easy to use.

I’m still a little torn on required/optional variants as it’s proved fiddly when needing to reference default props in framework components such as React, but maybe this could be solved by exporting a .defaultVariants for those use-cases 🤔

We're using React (with the component's props usually just extend-ing VariantProps (or &-ing), as usual. It has worked fine for us so far in dozens of components, and since we've added the stricter types we found things are easier to reason about and understand what's going on - things are more explicit.

In what cases do you need to reference the default prop value? These two options for APIs exposing this come to mind, in any case:

const button = cva({
  variants: {
    intent: {
      primary: "...",
      secondary: "...",
    },
  },
  defaultVariants: {
    intent: "primary",
  },
});

// Option #1
button.variants.intent // ["primary", "secondary"]
button.variants.intent.default // "primary"
expectTypeOf<button.variants.intent>.toEqual<ReadonlyArray<'primary' | 'secondary'> & {
  default: 'primary',
}>();

// Option #2
button.defaultVariants.intent // "primary"

Happy to see that we’re pretty aligned, and excited to hear how your fork continues

No further plans at the moment beyond the three things I added. I just published it since it looks like it could be useful for others. The timing couldn't be more coincidental though 😄

[TaraShevchenko]

Also came across a need for similar functionality (getting a config or variants). I am looking forward to the update with the addition of a feature adding this functionality. Thanks more for a great tool!

[fmonper1]

This would be a killer feature since it would ensure all our stories are automatically in sync with the variants we define

[bengry]

I've published a fork of this package that adds support for this, as well as a couple of other things we've needed using cva under the cva-extended package.
Do note that it's a breaking change from [email protected] since it has stricter types. Otherwise, it's a superset of cva's capabilities. It's published as cva-extended@2 just because of that, to avoid confusion with cva@1.

[joe-bell]

Tackling in #333!