Common styles merged into variants?

[TeknoFiend]

I'm trying to figure out the best way to have common styles that the variants build on. For example in the docs (https://theme-ui.com/theme-spec#variants) there is an example of button variants:

{
  buttons: {
    primary: {
      // you can reference other values defined in the theme
      color: 'white',
      bg: 'primary',
    },
    secondary: {
      color: 'text',
      bg: 'secondary',
    },
  }
}

But is there a way to specify common styles for all button variants, like if all buttons should have a borderRadius? Looking at how Box works in the source it doesn't appear that this is currently possible. I was able to simulate it by reimplementing Box and just changing the variant loading code to:

const variant = ({ theme, variant, __themeKey = 'variants' }) => {
  const fallback = get(theme, __themeKey + '.__default');    // "defaultButton"
  const defaultStyles = get(theme, __themeKey + '.__default', fallback);
  const variantStyles = get(theme, __themeKey + '.' + variant, fallback);

  return css( merge(defaultStyles, variantStyles) );
}

Perhaps this is not an expected usage of theme-ui or am I missing the correct way to accomplish "common" styles?

[lachlanjc]

Yep, this is absolutely a weakness of the Theme UI API right now. There is no great way to do this, though if you've split your theme into separate objects/files, spreading an object into each of the e.g. button variants is a decent option.

[TeknoFiend]

Thanks for the reply! yeah that's what I am doing currently but I was trying to find a way to reduce the total CSS generated.

Any interest in something like the above solution (supporting a built-in variant called __default or __base)? I can put together a PR but didn't want to bother if that was not the intended philosophical direction of Theme UI.

[lachlanjc]

Hmm. Personally I think that would be amazing. Maybe "shared" is the way to go? We're using "default" to mean what you get for a higher-level key (e.g. "blue" even if blue is an object of other shades), & I'm not sure those (default vs shared) are always the same, but perhaps they are. @hasparus?

[joernroeder]

there is also discussion about merging multiple variant together #1226

[TeknoFiend]

Having worked on this a bit locally I came up with a couple alternatives. One is to allow variant to take an array and apply (merge) each variant in turn. So, eg, a button could do this:

<Box as="button" __themeKey="buttons" variant={['base','primary']}>
  Primary Button
</Button>

This would match how emotion does "composition": https://emotion.sh/docs/composition

Alternatively the theme object itself could support "extending":

const myTheme = {
  buttons: {
    base: {
      // base styles
    },
    primary: {
      __extends: 'buttons.base'
      // extra styles just for primary
    }
  }

That's nice because it lets the theme-writer determine how styles are shared which is important for us because we accept the theme from the consumers (of our library) who don't control the JSX. But I don't know if that is contrary to the philosophy of the theme system. This is what we've done locally w/ a modified theme-ui and it seems to work pretty well for our limited use-case. We don't support multiple levels of __extends-ing but that seems like a natural extension.