Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Static CSS Extraction #1018

Closed
webchaz opened this issue Jul 20, 2017 · 7 comments

Comments

@webchaz
Copy link

commented Jul 20, 2017

I'm having a hard time finding any information on how to extract the inline styles to a separate file. Is this possible? Using extract-text-plugin in webpack or similar.

Thanks

@kitten

This comment has been minimized.

Copy link
Member

commented Jul 20, 2017

This is a tougher question to answer, but let me break it down 😄

We don't support static CSS extraction. You can try out emotion which does.

You might not need static CSS extraction actually, because of several reasons:

  • There's SSR which sends only critical CSS, instead of all static CSS, for the entire page. You don't even need to do SSR, but can use snapshotting (react-snapshot) or generate a static page (gatsby, et al), which basically saves a SSR result to a html.
  • Static extraction doesn't generate dynamic CSS, which means your page will either appear broken until the JS executes, or you'll need to defer until the JS is loaded
  • Caching doesn't actually buy you an advantage, because the JS bundles will likely always change in tandem with the extracted CSS

In v3 we will add preprocessing, which will actually a bigger advantage. As part of that we might support an option for static extraction, since the core library that will bring preprocessing will probably also be integrated into emotion, which does support extraction. So it might become an option. Or not 😉

I hope that answers your question.

Oh, bonus round while I'm at it. We won't support it in SC's standard form, because it doesn't work with our way of writing CSS. As mixins and static and dynamic CSS all have no specific specificity (all have the same importance), we order your CSS in the order you write it. This doesn't map at all to static extraction: https://gist.github.com/philpl/7b8a021f19ead2ec534091976a1ff6dc#file-2-specificity-md (This document explains way based on a simple example)

Emotion achieves static extraction by breaking with our previous assumptions and way of generating CSS.

@kitten kitten closed this Jul 20, 2017

@kitten kitten added the question label Jul 20, 2017

@kitten kitten changed the title Extract styles? Static CSS Extraction Jul 20, 2017

@webchaz

This comment has been minimized.

Copy link
Author

commented Jul 20, 2017

Thanks @philpl for the explanation and suggestions. It seems to be appending class names to styled-components instead of replacing old ones. Any reason for this? Basically for a simple button component that changes based on props, this seems to just grow infinitely.

screenshot 2017-07-20 19 13 45

@kitten

This comment has been minimized.

Copy link
Member

commented Jul 20, 2017

For every different CSS string per styled component there'll be a new class hash. As it's really unrealistic to reach a high amount of styles in non-artificial conditions, no one has complained about reaching a performance limit yet. Albeit there being one at the tens of thousands, where css injection slows down to a stunningly low speed.

But we have a fix for our comparably slow injection speed already. It's solved by using batching. Other libs use the speedy api which prevent you from editing css in production due to it. So we'll try batching first, which seems to increase the theoretical limit by a lot more again.

So to sum this up: Totally unrelated to the original question (No worries 😉) and not a big deal

@webchaz

This comment has been minimized.

Copy link
Author

commented Jul 20, 2017

@philpl Ha, Thank you - Yes I hijacked the same question. That sounds great though, loving styled components so far. Thanks again for detailed responses.

@xinzhang

This comment has been minimized.

Copy link

commented Jan 29, 2019

@webchaz this inline styles actually an issue for us especially when we running the web site in cloud and they charge by egress network data size. we have a unzipped 1.5MB html page and 1.3MB styles inline, it is gzipped as 200KB but it is still too large. Is there any suggestion what we can do? By the way, we are using Next and calling sheet.getStyleElement() to have all the css which is what Next needed.

@kitten

This comment has been minimized.

Copy link
Member

commented Jan 30, 2019

@xinzhang That does sound like quite the egress issue. I assume that means you're server rendering all pages? As it so happens, I think there's a way to export the SSR'd styles into an external CSS file, which of course only makes sense if you're prerendering your pages and are statically exporting them. Are you CDN caching your pages?

@xinzhang

This comment has been minimized.

Copy link

commented Jan 31, 2019

@kitten , I think there's a way to export the SSR'd styles into an external CSS file --> as we do ssr, this is really what we need. Currently the code in _Document is like below,

static async getInitialProps(ctx) {
    const sheet = new ServerStyleSheet();
    const page = ctx.renderPage(App => props => sheet.collectStyles(<App {...props} />));
    const styleTags = sheet.getStyleElement();
}

Then in the render() function, we have to include the styleTags in the html.

render() {
    return (
      <html lang="en">
        <Head>
          {this.props.styleTags}
        </Head>
        <body>
          <Main />
        </body>
     </html>
  )
}

I wonder if we can output this styleTags into a separate file and I don't know how. because this is the whole part of the process of the Next framework to return a SSR page.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.