Why does emotion have to repeat all css properties for every little change?

[faradaytrs]

For example, we have two blocks:

const divCss = css`
    background-color: red;
    padding: 10px;
    border: 1px solid blue;
`;

<div css={divCss}></div>
<div css={divCss}></div>

This will result in two divs having the same classname, which is expected.
But if we add one dynamic variable:

const divCss = css`
    background-color: red;
    padding: 10px;
    border: 1px solid blue;
`;

<div css={[divCss, {color: "yellow"}]}></div>
<div css={[divCss, {color: "white"}]}></div>

It will result in them having completely different classnames, and although most of css properties they use are the same and obviously static, it will copy paste them many times under different classname.

If we have many versions of the same element on the page with a lot of static css and just one line difference it will result in large build size.

Why can't emotion detect static part of the css and detect separate classname for static and dynamic styles?

It would be awesome if it generates:

.classname1 {
    background-color: red;
    padding: 10px;
    border: 1px solid blue;
}
.classname2 {
    color: yellow;
}
.classname3 {
    color: white;
}

And then just combines them accordingly:
````html
<div classname="classname1 classname2"></div>
<div classname="classname1 classname2"></div>

I can kinda manually achieve such result by using className property in combination with cx. But it will generate styles in runtime instead. Only css property is handled by compiler.

[faradaytrs]

I found that this is called static extraction? I understand that automatically extract properties might be difficult, but what i ask is just let me control generated classnames manually and not in runtime. Kinda make css property work similarly with className + cx.

[srmagura]

Hey @faradaytrs, I have an open PR about adding a "Best Practices" page to the docs. This section about dynamic styles may be of interest to you.

As you said, you can use @emotion/css to generate CSS classes at runtime. It does give you more control over those class names than @emotion/react.

Currently, Emotion does not do static extraction, unless you count some of the CSS prop optimizations done by @emotion/babel-plugin. If you are interested in static extraction at compile time, there are libraries for that. The one I have heard of is Vanilla Extract.