Cannot use conditions inside custom utilities

[adbutterfield]

Description

I'm creating a design system with Panda. We have many components that change color or background color for hover/active/disabled states. Result is there are a lot of classes added to simple elements (like buttons) 4 classes for color and 4 classes for background color, maybe 4 classes for border.

I had an idea that if we could create utilities that group the base + states for a color option (like primary text color) we could get one class instead of four, taking components that need to set color/background color/border down from 12 classes to 3. Utilities are also highly reusable across different components.

But I was sad to find out, that conditions are not supported inside utilities...

I'm not sure if this is a bug, or just an unsupported feature?

Link to Reproduction

https://stackblitz.com/edit/vitejs-vite-qwrsbf?file=src%2FApp.tsx

Steps to reproduce

1. Go to the reproduction
2. Check the two buttons
3. primaryBorderWorks only sets border and works fine
4. primaryBorderNoWorks sets base/_hover/_disabled and does not work

JS Framework

React

Panda CSS Version

latest

Browser

No response

Operating System

• macOS
• Windows
• Linux

Additional Information

No response

[eastdraconis]

I thought the base part was removed when declaring CSS.

I haven't created and used the utility, but I've tried to reproduce it and it looks like I can't use the conditional style

primaryBorderNoWorks: {
        values: { type: 'boolean' },
        transform(value) {
          if (!value) return {};
          return {
            border:'1px solid black',
            "&:hover":{
              border:'1px solid blue'
            },
            "&:disabled":{
              border:'1px solid gray'
            }
          };
        },
      },

If you try it with this code, it should work as you want!

[adbutterfield]

That's nice for a workaround. Definitely better DX if we could use the utilities though...

[segunadebayo]

This is by design. Utilities are Panda's fundamental building block and should transform directly into CSS objects.

This is important for performance and speed. I'd recommend that you import the default conditions and use them in the selectors if you need to reference them.

If you're trying to shorten the className, you probably want to use a config recipe instead.

[adbutterfield]

Interesting.

I'd recommend that you import the default conditions and use them in the selectors if you need to reference them.

I thought about this too, maybe I'll give it a try.

If you're trying to shorten the className, you probably want to use a config recipe instead.

Config recipe doesn't really fit this use case. I still want a reusable atomic class that I can apply to multiple components, but I want it to handle the case of base + states for a single property.

I guess config recipe would work for components that only have one color scheme, and I could combine it with any local styles needed for each component. But for a case like my button component that has primary/secondary/etc, not as easy to use.

[caseybaggz]

@segunadebayo I honestly don't love that answer and believe that it contradicts the design of everything else in Panda (i.e. to create a pleasant contract for creating a style-based system).

For example, my use case is more intense because we are building a Multi-themeable (and mode) Design System. We specifically chose Panda for our foundation because it provides such a great experience for creating a system that holds you accountable to decisions being made for implementations.

Our problem

On that note, we have themeable gradients which is slightly problematic for the current API on a few levels.

1. Gradient configs can only reference primitive color tokens
2. Gradient configs must be static (which is fine - I get it)
3. Utilities cannot use conditions

I could have saved so much code and had a cleaner codebase if at the bare minimum, our gradient configs could source our semantic tokens - but they can't (or at least I haven't found a way yet?)

Our Hack (I don't love)

Because of the list above, we are having to go way out of our way just to create themeable gradients with a delightful DX via using a utility.

We solved this problem by doing the following (seems so unnecessary):

1. Create Gradient primitives for literally every single option (theme-1-dark, theme-1-light, theme-1-system, theme-2-dark, etc.)
2. Create a "hidden" semantic token gradient group for storing text tokens that can adapt to themes (used in the utility)
3. Create a utility hack that returns the gradient value depending on static conditions 😭

All of that...just so our users can do this:

css({ gradient: 'charon-light' })

If we could reference the semantic tokens in our gradients config - this would be no issue.

🤞 You can and I'm just overlooking something 👀