Replies: 2 comments 2 replies
-
It seems like you might be after the |
Beta Was this translation helpful? Give feedback.
2 replies
-
I think this looks like a much more composable api design than the existing one. But it would be a pretty hefty breaking change. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi team! I'm Big fan of
vanilla-extract
, and my team’s been using it extensively in our projects. We use CSS variables a lot to create flexible styling interfaces that make it easy to customize components beyond the props.For example:
Ideally, we’d like to declare these CSS variables with
createVar
without worrying about conflicts, but right nowcreateVar
returns avar()
wrapped string:While there are workarounds (like declaring variables manually, using utilities with
functionSerializer
, or calling the privategetVarName
), I’m wondering ifcreateVar
really needs to wrap the output invar()
. Without this wrapping, we could simplify things and skip some extra abstraction.Here’s how it might look without the
var()
wrapping:Pros
Direct usage within
style()
without needing avars
property:Cleaner inline styles without needing
assignInlineVars
:Cons
For cases where
assignVar()
is needed, or where variables are used directly as values withinstyle()
, we’d need to manually wrap them withvar()
.Curious to hear your thoughts on this approach. I think it could streamline some workflows and make vanilla-extract even easier to use. Thanks for taking the time to consider it!
Beta Was this translation helpful? Give feedback.
All reactions