Proposal to add responsive variants to Recipes #1375
Replies: 2 comments 2 replies
-
| I needed something similar to this when i wanted recipes to automatically compile into sprinkles, so I made this: https://www.npmjs.com/package/vanilla-extract-recipe-factory. Now, it’s a bit different from your use case but we both felt that the regular recipe function isn’t enough for what we need, so we built a new one. We’re likely not alone in this, so what’s the proper course of action for vanilla extract? I honestly think it’s fine the way it is. I think it’s really hard to provide a super flexible recipe function that satisfies everyones needs. Instead what vanilla extract does really well is to expose highly composable primitives, which the community can then use to build more specific and opinionated solutions. So why not release your recipe function as its own package? | 
Beta Was this translation helpful? Give feedback.
-
| Decided to just package it myself. Closing this one. For the ones interested: https://www.npmjs.com/package/responsive-recipes | 
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi! ✋🏼
For utility components like
Stack,Gridand other UI components likeButtonandModalwe have variants that need to be set per breakpoint. For a large scale project at work I've forked the repo and created something that works perfect. Wanted to share my idea and check out the API and see if it's something worth merging. I've seen this mentioned in other discussions (#1125, #1363, #497), but wanted to do my own proposal in its own thread.For clarity. The goal is to have usage in React like the following:
As you can see, heavily inspired by Stitches.
Simplified working example on type level
I have created a simplified example of the API that works on type level: https://tsplay.dev/WvoPkw
API
In order to create the above, we need to be able add breakpoints. I wanted to stay as close as possible to Sprinkles, so we've called these conditions. Also; you don't want to specify breakpoints for every recipe that you create. So we have a factory function that takes in a set of
conditionsand returns arecipefunction, just like the regular recipe API. It also needs aninitialConditionfor the use case where we use a responsive variant in a static manner (<Stack direction="row" />). Although, it's more of a fallbackCondition, I guess.If you don't want to use responsive variants, you can skip this step and just import
recipefrom the @vanilla-extract/recipes package.Responsive variants
In order to keep the current API intact, I've introduced a
responsiveVariantskey. Only the variants defined here will be compiled to every breakpoint in the conditions passed tocreateRecipeFactory, similar to Sprinkles.This could be used as follows:
Default variants
These are now type checked through
variantsandresponsiveVariantsand applied accordingly.Compound variants
These are correctly type checked through
variantsandresponsiveVariantsas well. But more importantly, when a responsiveVariant, that is part of a compoundVariant, is set to a certain variant on a certain breakpoint, the compoundVariant should kick in as well.This is a simplified (and dumb) example. But when we have the following runtime execution:
The compound variant
small+spaciousshould only kick in starting from thesmcondition.Overriding default conditions
This is not something that I've needed (yet?). For more granular control we could add a
conditionsproperty to a recipe that would merge (or override -- would be my personal preference) the passed default conditions inside ofcreateRecipeFactory. You can see a simplified working version in the Playground posted above.Of course, a potential simple alternative to this would be to just create a second
recipefunction with thecreateRecipeFactoryso we don't need theconditionsproperty inside of a specific recipe at all:Closing notes
This worked very well for us in our projects. Open to any suggestions! I've tried to minimize the impact on the existing API as much as I could. But I'm aware this will obviously have some impact on the codebase and would need to be maintained as well, etc.
Again, check out the playground to see how everything works on an API and type level: https://tsplay.dev/WvoPkw
Beta Was this translation helpful? Give feedback.
All reactions