Allow children to be styled in styleVariants and recipe

[AndrewLeedham]

I understand and agree with why style() cannot style children, as it creates separation between blocks of styles affecting different nodes.

However, I believe there is a case to allow it for variants. Variants are often directly linked to props of a component, and therefore affect children of said component. For example say you have a button component with a size and colour variant, you would likely want these variants to affect the background and border at the top but also the text colour and icon colour etc. of children.

You can use the recipe along with globalStyle to style children. This does not seem like a first-class usage though as you have to split the resulting string as seen here: #464. Also, adding a base class offsets the variant you want and there is not guarantee of the class output order.

Therefore, it seems to me that allowing children to be styled via selectors would make sense in styleVariants and subsequently recipe?

[ArmandPhilippot]

Hello,

I'm here because I was experiencing a similar issue as #464. I agree with @AndrewLeedham, the mentioned solution is not ideal. It affects readability and it doesn't seem very intuitive...

But I don't think it is necessary to allow styling children via selectors. We can create a styleVariants or another recipe for the children and pass down the class. (I admit that sometimes this solution is not suitable...)

For example, let's say I have a recipe for my parent like the following:

export const parent = recipe({
  variants: {
    alignment: {
      horizontal: {
        display: 'flex',
        flexFlow: 'row wrap',
      },
      vertical: {
        display: 'block'
      },
    },
  },
});

Now let's say that depending on the parent alignment, I'd like to style its children with different properties. These children can also have some variants. So I create another recipe to style the children (or I could use styleVariants):

export const child = recipe({
  variants: {
    border: {
      false: {
        selectors: {
          [`${parent({ alignment: 'vertical' })} &:not(:last-child)`]: {
            marginBottom: '1rem',
          },
        },
      },
      true: {
        selectors: {
          [`${parent({ alignment: 'horizontal' })} &:not(:first-child)`]: {
            marginLeft: -1,
          },
        },
      },
    },
  },
});

The generated class name for child is passed down to the children components. This approach works as expected.

However, if later I add a base property to the parent recipe. It breaks the selectors in child since it is now returning something like component_parent__11riky41 component_parent_alignment_horizontal__11riky42.

Before adding the base, the parent({ alignment: 'horizontal' }) was returning something like: component_parent_alignment_horizontal__11riky41 (there is a leading space but it is removed when I post...)
This leading space does not affect the selector, the styles are applied.

So to avoid breaking things later, I have to apply the solution mentioned in #464 (by adding .split(' ')[1]) all the time like this:

export const child = recipe({
  variants: {
    border: {
      false: {
        selectors: {
          [`${parent({ alignment: 'vertical' }).split(' ')[1]} &:not(:last-child)`]: {
            marginBottom: '1rem',
          },
        },
      },
      true: {
        selectors: {
          [`${parent({ alignment: 'horizontal' }).split(' ')[1]} &:not(:first-child)`]: {
            marginLeft: -1,
          },
        },
      },
    },
  },
});

When the recipe is used inside a selector, I expect it to return only the matching class and not the base class.

If it is not possible, maybe a note in the documentation ( https://vanilla-extract.style/documentation/styling/#complex-selectors or in recipe package ) with the recommended approach could be helpful.

[askoufis]

Recipe class names are now directly accessible from the recipe function, which solves this issue where you don't want the base style.

[aarongoin]

Yes, I think for layout components specifically this is really useful. For example I have the following use case where targeting children is the whole point of the component:

<Box display="column" space={4}>
  {/* arbitrary child nodes laid out in a column with spacing level 4 of margin between them */}
</Box>

You can see how in this instance the children needing to be aware of their parent and apply the style themselves is not really tenable (which is the current solution that vanilla-extract proposes). If I implemented it the vanilla-extract way I'd have to pollute the styles of every possible child, or be forced to create some component to wrap every child in order to use them in the parent layout. These aren't good solutions when css already gives us a better one.

In my current implementation I iterate over all the child nodes (in Box component's render method) in order to apply margin to them in accordance with my space prop, but I don't really like this either as this really should just be a static css child selector like:

"& > :not(:first-child)": { marginTop: "blah" }

So I'll likely refactor a bit to add static css classes outside of vanilla-extract, which is not ideal for keeping my styles colocated, but will be the most performant solution right now in lieu of vanilla-extract supporting child selectors.

[askoufis]

Sorry for the incredibly late reply.

I think for this use case there's a few options you could go with that don't involve applying a classname to every child (though this isn't really that bad IMO). I don't know if I'd couple a column layout to Box over an explicit Columns component, but that's a separate concern.

You can just write the global style you have above using globalStyle, though you'd have to use a CSS variable to change marginTop based on a prop:

const columns = style({});
const columnsMarginTopVar = createVar();

const spaceOptions = {
  '1': '1px',
  '2': '2px',
  '3': '3px',
  '4': '4px',
};

globalStyle(`${columns} > :not(:first-child)`, {
  marginTop: columnsMarginTopVar,
});

export const columnsMarginTop = styleVariants(spaceOptions, (space) => [
  columns,
  { vars: { [columnsMarginTopVar]: space } },
]);

You could then select the space style you want in your component, e.g. columnsMarginTop['4'], and that would give you a composed style containing the columns classname and the appropriate classname for the style that assigns your selected space value.

Or you could update the CSS variable at runtime if you want.

The other option would be to just use flex gap.

[juice49]

I just ran into this myself. I'm not sure whether it's a good solution yet, but I created a recipeGlobalStyle function to at least make it tidier to create global styles based on a variant:

import { GlobalStyleRule, globalStyle } from '@vanilla-extract/css'

function recipeGlobalStyle(
  recipeSelector: string,
  selector: string,
  rule: GlobalStyleRule,
): void {
  globalStyle(`${recipeSelector.split(' ')[1]} ${selector}`, rule)
}

import { recipe } from '@vanilla-extract/recipes'

const stack = recipe({
  variants: {
    size: {
      large: {},
    },
  },
})

recipeGlobalStyle(stack({ size: 'large' }), '> * + *', {
  marginBlockStart: '3em',
})

Although I can see why this might be discouraged, it's a powerful CSS capability, and I think it's a shame it's disallowed altogether.

[PanchoBubble]

Thanks mate, they really need to handle children selectors if they want people to use the library on big scale.
I was struggling to update an svg path based on a variant, was impossible to handle if not 😓

[askoufis]

Recipe class names are now directly accessible from the recipe function. This helps a bit with the above implementation.

@PanchoBubble You'll find there is plenty of "big scale" usage of Vanilla Extract in the wild. The entire point of the library is to enable anyone to make their own abstractions that fit their use case, as @juice49 did. Catering to every possible use case in the main library is impractical and would just bloat the API.

Recipes is just one implementation, and isn't even part of the main library, instead relying on the power of addFunctionSerializer. You could create your own recipe implementation that does what you want using it.