Anyone using cva (atomic recipes) for their component library?

[cgatian]

I've been looking at using config recipes for our component library, but find that since they are JIT compiled it makes it harder for consumers to reuse these recipes within their app. If we want a consumer to reuse the config recipe we have two options:

1. The library ships the recipe configured with staticCSS.
2. Have the consumer enable staticCSS on the recipe they want to repurpose.

In addition, if a consumer were to publish a NewButton based on the Button (using config recipe). They would need to then notify all consumers of the NewButton to also include the staticCSS option for the button recipe. I feel like this just doesn't scale well.

Given these drawbacks, I'm considering using atomic recipes instead (cva) for the component library. This will allow consumers to reuse the recipe within their app without any additional configuration. The drawback to this approach is that the atomic CSS is always included regardless of whether the consumer uses the component. But has the benefit of using atomic CSS, in which the CSS size should eventually plateau.

Some questions:

1. Has anyone used onlycvas approach for their component library?
2. Is there a better approach?

In evaluating PandaCSS for our organization I'm left wishing there was some middle ground, where only components included in the application are generated with atomic CSS. I understand this is what config recipes try to solve, but find the extra configuration required a bit cumbersome. I would love to know how others are dealing with this.

[segunadebayo]

Here's a project that uses cva for its primitives
https://github.com/NDLANO/frontend-packages/tree/master/packages/primitives

Maybe @Jonas-C can chime in as well to share their thought process.

For shipping config recipes in a design system, I generally prefer pre-generating the styles so you don't have to worry about the JIT stuff.

You can also configure the recipe.jsx options to use a regex that catches all "Button" related names.

[cgatian]

Thank you for the response!

[Jonas-C]

Hey, @cgatian. We struggled with the same thing you're currently dealing with, and opted for cva due to the same reasoning you specified. At some point I also spoke a bit with Alex (@astahmer) about this on Discord, where he stated that having a more involved tracking solution would introduce too large of a perf overhead. We did a couple of things to make cva a little more "livable":

1. Generate a css and buildinfo file for every package in your component library.
2. Split up your component library into packages. For us, it felt natural to create one for our preset and one for our primitives. That way, a consumer could choose to only import css related to our tokens. Our reasoning was that most people don't jump into a design system to only use a single component. You're usually all in.
3. Find a way to consistently merge atomic css. Merging styles when you're using atomic css can be kind of a pain. There's no guarantee that the styles applied in the re-styled component gains priority when the component is actually rendered. We ended up writing a plugin to consistently handle those cases. We're currently the only ones consuming it. I haven't gotten around to publishing it officially yet, so let me know if you need us to do so.

I'm trying to write some general documentation around our usage of panda as a whole. There might be some useful stuff about the plugin and the general inner workings of cva in there. NDLANO/frontend-packages#2561

[cgatian]

Thank you for the detailed reply! The linked PR was also an interesting read, thank you for sharing.

Could you clarify this:

Split up your component library into packages

I think you're saying to split your styled-system off into a package and make ui-components a separate package. You're not saying make individual packages for button, select, pill, etc., right?

[Jonas-C]

I'm thinking of something in the middle. Your styled-system should definitely be its own package.

We decided to split our design system into something like five packages:

• preset-panda contains the plugin and our own preset.
• Primitives contains all general usage components, and allows consumers total freedom w.r.t styling and composition. It's basically a mirror of park-ui.
• ui contains less generic components, with less consideration for styling and composition. This is usually things with a bit of business logic that most consumers won't touch.
• Remaining packages are mostly single-exports of large components that some specific consumers might use. For instance, we have one named image-search that exports a single component to be used with our API.

We generally only assume that a consumer will make use of primitives.

[adbutterfield]

We're also using css/cva for the component library for our design system. We split into 3 packages: styled-system/react/tokens(which also includes our preset). We've got something like 120 components now, and the css file is like 26k.

[cgatian]

@adbutterfield, 26k uncompressed?

[adbutterfield]

Ah yeah, that's compressed size.