Theme-ui: Rationale behind using emotion

[heauton]

Mind asking what made you choose emotion for this project? You seemed to use styled-components in the past (e.g. rebass) since this is a relatively new project and now that you've worked on a bunch of css-in-js libraries, do you personally prefer emotion at this point?

[jxnblk]

Styled Components and Emotion are both great libraries. The decision to use Emotion here was based on a few factors for what we're intending to do, including:

• The Emotion API includes lower-level utilities, like createEmotion that we're considering leveraging
• Emotion's implementation of the css prop and the custom jsx pragma allows for potentially better integrations with @styled-system/css
• We might ditch the styled HOC API altogether, and Emotion's packages are better setup to only ship what you need

That said, if you're building a custom component library with the styled HOC (a la Rebass), both styled-components or emotion are fine choices to use

[heauton]

Thanks! That makes sense. 🙂

[elektronik2k5]

It is also worth mentioning that emotion, unlike styled, supports source maps.

[TheSisb]

We might ditch the styled HOC API altogether, and Emotion's packages are better setup to only ship what you need

Any chance you could provide more color to this idea? I personally dislike having two ways of doing the same thing, but I couldn't decide which approach I liked best yet.

[jxnblk]

@TheSisb as of v0.2.0, we've removed the @emotion/styled package, but use a smaller implementation with a similar API. For many components, something like the following example works similarly to how the styled HOC works, but with syntax that's more like any other React component:

const Box = props =>
  <div
    {...props}
    css={...styles}
  />

You can extend upon this approach to add custom style props and strip out component-specific props with destructuring