Upgrade Emotion's theming to interpolate scales in css prop

[ianstormtaylor]

The problem

The idea of using interpolated "theme scales" seems pretty mainstream now in the CSS world. It seems like theme-ui / styled-system is the gold standard for this kind of thing. For example for a theme of:

const theme = {
  space: [0, 4, 8, 12, 16, ...],
  colors: {
    red: { ... },
  },
  fonts: {
    sans: 'ui-sans-serif, system-ui, "Segoe UI", Roboto, "Helvetica Neue", Arial, "Noto Sans", sans-serif',
    serif: 'ui-serif, Georgia, Cambria, "Times New Roman", Times, serif',
  },
}

Using theme-ui you could write:

const Component = (props) => (
  <h1
    sx={{
      color: 'red.500',
      fontFamily: 'sans',
    }}>
    Hello
  </h1>
)

Or similarly using styled-system you could create your own components to write:

<Box color="red.500" fontFamily="sans">
  Hello
</Box>

Or even using something like Tailwind you could do something similar:

<div class="font-sans text-red-500">
  Hello
</div>

Right now this is possible with the function-based API in Emotion:

<div css={theme => ({ color: theme.colors.red[500], fontFamily: theme.fonts.sans })}>
  Hello
</div>

But this is more verbose than the existing solutions because of (a) the need to create a function, and (b) the mapping layer isn't smart about specific properties.

Proposed solution

I think this pattern is so commonplace that Emotion should actually move to support it out of the box, potentially with an addition to ThemeProvider that would allow for interpolating elements directly from the theme. It could be as simple as:

<ThemeProvider theme={theme} interpolation={interpolation}>
  ...
</ThemeProvider>

Where interpolation is a default that ships with Emotion for the mapping between properties (similar to theme-uis mapping).

This would allow using Emotion's existing css prop to do:

<div css={{ color: 'red.500', fontFamily: 'sans' }}>
  Hello
</div>

Bringing this functionality into Emotion could actually set a new baseline, and eliminate the need for UI libraries to have to solve these problems themselves. For example chakra-ui which uses Emotion currently has a mix of theme-related props and component-related props, like:

<Button colorScheme="red" fontSize="md" onClick={...}>
  Click
</Button>

They've had to implement the fontSize="md" logic on their own even though they use Emotion, and keeping track of which properties are CSS ones and which are component-specific ones is tedious. Every other component or UI kit has the same issue. When it could be nicely separated as:

<Button colorScheme="red" onClick={...} css={{ fontSize: 'md' }}>
  Click
</Button>

If it were at the Emotion level, all other UI components could benefit from the same terse theme interpolating, so that when you had to use different components for autocompleting, layout, tables, etc. (which invariably no single UI kit seems to provide) you can maintain the same "themeability" across all of them.

Additional context

I think this is an area where a lot of value could be provided in Emotion streamlining this process and offering a sane default out of the box. Technically this is possible by integrating theme-ui/styled-system with Emotion, but this process is much more convoluted.

[MMT-LD]

From using emotion for a while and both styled-system and theme-ui - i think this goes against what emotion is trying to do/be. The reason why theme-ui/style-system implements on top of emotion is because thats the point of emotion imo. It's a low level api that can be extended to suit anyone's needs.

Im not sure supporting this would be a good idea out of the box. A separate package maybe with some defaults... However, that being said i kinda like emotion the way it is 😄 - but hey that just my opinion

[Andarist]

Ye, while I definitely see the merit of those scales and I can recommend using those for all projects to maintain consistency etc I see Emotion as a more low-level library. There are already competing schemas of/approaches towards this kind of thing and I wouldn't like to impose my opinion on all users.

[ianstormtaylor]

Hey, thanks for the replies. I hear what you mean about being "low-level", but please consider what I'm asking for—not even the entire thing potentially, but being open to the idea.

I agree with you that Emotion's @emotion/css is a low-level library. But I don't really think Emotion as a whole is... if it were, it wouldn't have re-implemented the styled API and would let styled-components solve that problem instead. And I say that as a compliment to Emotion, because I don't really think the reason people use it is because it's low level. At least speaking for myself, I like Emotion because it simplifies the complexities of dealing with all the inter-dependent CSS-in-JS concepts. I generally trust it in terms of API design, and have felt so far like any new CSS-in-JS best practices have been nicely folded into the API. (I think the folding of Glamorous into Emotion was amazing, and I'd hope that styled-components would do the same some day.)

There's no need for it to deviate from it's current usefulness in the community of providing low-level exports like @emotion/css or even smaller things like @emotion/unitless. The fact that it is built up of small pieces that are consistently designed is awesome.

That's where "scales" come in...

They are a newer, but now very popular concept. But there is a ton of fragmentation in how they are implemented. This causes headaches in lots of ways—with theme-ui overriding the @jsx pragma, with libraries like chakra-ui that then wrap the entire set of tools once more. The nesting doll approach to the ecosystem makes dealing with CSS-in-JS more and more complex over time.

And that's exactly the sort of problem that Emotion can streamline for people, the way it has with other CSS-in-JS concepts.

I was actually going to write a whole section about how if Emotion doesn't do this, it will inevitably be solved by other tools which are willing to offer a better "all-in-one" experience—but that was before I came across Stitches which is already starting to do exactly that. This will only accelerate.

I'm not arguing that you change @emotion/css—it should stay low-level. But @emotion/react does not need to be low-level, and actually does a disservice to its users if it choose to stay "dumb" in that respect.

It's not something that needs to start out complex either. The interpolation logic built-in to @emotion/react could easily default to an identity function. And the actual logic for handling the scales could be in a new package like @emotion/scales which allows you to opt-in to the scaled-based logic.

Thing is... defining a set of shared common variables—or "design tokens", or whatever you want to call them—is not a very complex addition, and it's such a core piece to how people are using CSS now, that if Emotion doesn't solve it it's just making things more complex for its users, and other tools will decide to offer a better experience by bundling it.

[emmatown]

This could be implemented with a Stylis plugin - https://codesandbox.io/s/confident-bhaskara-nn9el?file=/src/App.js