API Consequences for Static CSS Extraction

Phil’s excellent work on the babel plugin means that we can extract all non-dynamic styles into a static CSS stylesheet.

However, we need to think about the effects this has on the project. Take this code,

const Button = styled.button`
  background: ${props => props.primary ? 'palevioletred' : 'white'};
  ${props => props.large && css`
    font-size: 2em;
  `}
`

While it is theoretically possible for this use-case to extracted into static CSS, we don’t currently have this optimisation. Further more, we won’t be able to optimise every case.

We can work around this.

const Button = styled.button`
  background: white;

  &.primary {
    background: palevioletred;
  }

  &.large {
    font-size: 2em;
  }
`

<Button className="primary large">It mostly works like before</Button>

This can now be completely statically extracted.

However, this is no longer idiomatic styled-components. But we can guarantee people will do this for the sake of optimisation.

We need to continue static style extraction. But we also need to consider what we can change to have an idiomatic styled-components that better supports CSS extraction. Even if that changes what ‘idiomatic styled-components’ is.

Pinging @mxstbr @geelen @philpl

[kitten]

@jacobp100 it requires more effort, but it should be possible. Mixins are not as simple though, since they might be external. This means that we’d need an internal method that adds more classnames to a styled component and need to generate our own ones for them.

Even then, I believe that we can enhance this as we go

[jacobp100]

When interpolations are used

That’s sort of what I’m getting at. Interpolations are used for mixins, variables, passing arbitrary props, conditionally applying styles, and more. Can we do any of these in a way that can be statically analysed?