Emotion: Css classes are not splitted to treat output CSS effectively

[adambisek]

After reading documentation and googling I nowhere found, how to make Emotion effective and split produced css code.

Version of Emotion:
I have this issue on latest v 10.

Repro steps:
I have component like this:

import styled from '@emotion/styled'

const StyledInput = styled.input`
  box-sizing: border-box;
  border: slim;
  border-color: red;
  color: ${(props: any) => myfunction(props.color || 'black')};
  width: 100%;
`

And I use it two times like this:

<StyledInput color="red" />
<StyledInput color="green" />

Current CSS output:

.class1 {
  box-sizing: border-box;
  border: slim;
  border-color: red;
  color: red;
  width: 100%;
}
.class2 {
  box-sizing: border-box;
  border: slim;
  border-color: green;
  color: red;
  width: 100%;
}

Expected CSS output:

.commonClass {
  box-sizing: border-box;
  border: slim;
  border-color: red;
  width: 100%;
}
.class1 {
  color: red;
}
.class2 {
  color: red;
}

[Andarist]

This is explicitly not a goal of emotion. Emotion does a bunch of stuff at runtime (and is fast at doing them!) and this would only slow it down without really yielding any real benefits (especially compared to runtime overhead implied by this). It would also be harder to do a composition of styles and you would be endangered with insertion order problem - described in more detail here: https://emotion.sh/docs/composition

[tomchentw]

@Andarist May I confirm with you about the composition issue that I encountered today? From what I read here, it's the same issue in this thread. Details:

CodeSandbox: https://codesandbox.io/s/issue-with-emotionstyled-composition-wlh9h
Full-Res Screenshot: (just in case CodeSandbox breaks)

I'm new to @emotion and if this is intended by design, I will update my codebase because

It would also be harder to do a composition of styles and you would be endangered with insertion order problem

I strongly agree the approach that emotion takes here. Given the large codebase, the benefits of it become more significant. Thank you for answering 👍 💯 🥇

[Andarist]

What's the issue that you are seeing? That you see the same class names being duplicated? This is most likely due to hot-reloading and emotion losing the state what it has already injected to the document, but the document itself being reused.

[tomchentw]

@Andarist my expectation would be :

1. SubInRed will inherit the class name from Sub
2. Hence, the adjacent selector in Title will turn on Sub's display attribute.

Instead, I got:

1. SubInRed will NOT inherit any class name from Sub.
2. The adjacent selector in Title will not affect SubInRed.

Previously this will work with the library where I came from (linaria). But from reading your comment above in this issue, I think this was the expected behavior by design. <- I just want to confirm this with you.

Thanks!

[Andarist]

Sub and SubInRed are treated as completely separate components - each has its own unique class name and thus they SubInRed won't be targeted by Title's styles.

Technically we maybe could change this behavior, but I'm not convinced that we should. You could raise a separate issue about this so we could discuss this - we are working on v11 so this potentially could make it into that release, although keep in mind that we probably won't decide to support this.