Multiple inheritance (Composition)

Is or would the following be possible?

export const Card = styled(Rounded, Column)

otherwise I have to do the following

export const Card = styled(RoundedColumn)

Which is alright, but add more code.

[kitten]

I’d suggest you to use mixins with the css helper in this case, since it’s not really an inheritance problem, but a compositional problem.

Let’s say you put the code for rounded elements in a rounded mixin:

import { css } from 'styled-components'

const rounded = css`
  border-radius: 5px;
`

And the one for columns in a column mixin:

import { css } from 'styled-components'

const column = css`
  display: block;
  flex-shrink: 0;
  flex-grow: 0;
  flex-basis: 25%;
  width: 25%;
`

Then you’d define your card like this:

import styled from 'styled-components'

const Card = styled.div`
  ${rounded}
  ${column}
`

We’re still missing a section on mixins / composition in the new documentation, but an explanation of the helper itself can be found here: https://sc-next-docs.philpl.com/docs/api#css

Edit: I changed the title in the hopes that someone searching for this, will have an easy time finding it 😃

[kitten]

@joetidee this would be a question that’d be more suited for spectrum or a new issue, but let me elaborate on it here 😃

First of all I’ll change the two categories of answers up a little bit. As a CSS-in-JS library they don’t really suit either disciplines we span perfectly.

The mixins in styled-components or similar libraries are rather different than pure compile-to-CSS mixins (think Sass), since they exist during JS runtime.

So A and B would sound more like the following to me:

A) Is the mixin computed into a combined CSS template in styledComponents, or

B) Are separate CSS classes created for mixins?

In styled-components the answer is: A. Mixins are flattened into a StyledComponent’s style “template.”

This doesn’t have any effect on your everyday-use. Even in SSR this is negligible as long as your SSR results eventually are gzip’d.

B is not an option in the answers you’ve outlined since they’re just tagged templates, so arrays of strings and interpolations.

They’re still functionally composed in that, without side effects they’re merged into the rest of a StyledComponent’s template.

But they’re also technically preevaluated at runtime, which means they’re “copied” into another template.

This is to preserve specificity, which trumps everything else in our case. We expect the mixin to always apply at the case you interpolate it into, respectless of what comes after. If something after the mixin overrides its rules that needs to be respected. Hence we merge the mixin into a component’s rules. Which is also important when a mixin is used multiple times.

At runtime we make sure that the tagged template literal css function already preformats the rules to evaluate non-function interpolations, so this is as efficient as we can make it.

Tl;dr: in SC mixins are inlined into the rest of your rules during runtime. This leads to duplication only during SSR, which is fine with gzip.