Twin.macro emotion example flickering when build for production

[armspkt]

1. The buggy behavior you’re experiencing and what should be happening instead
   I tried this example https://github.com/ben-rogerson/twin.examples/tree/master/next-emotion
   but when I build & start (for production) then go to localhost:3000 and refresh page the UI seems flickering.
   It does not happen in the development mode.

After some debugging seems like calc css function not call on server-side

I guess

2. If you're using styled-components, emotion, goober, or something else
   emotion

3. A link to a minimal demo showing the bug in action
   fork this repo https://github.com/ben-rogerson/twin.examples/tree/master/next-emotion
   and use yarn build && yarn start

[ben-rogerson]

I'll have to look into this futher - perhaps there's something to be learned in this article.

[williamtetlow]

I found that adding the CacheProvider to _app fixed the issue

import { CacheProvider } from '@emotion/react'
import { cache } from '@emotion/css'
import { GlobalStyles } from '../components/GlobalStyles'

function MyApp({ Component, pageProps }) {
  return (
    <CacheProvider value={cache}>
      <GlobalStyles />
      <Component {...pageProps} />
    </CacheProvider>
  )
}

export default MyApp

[ben-rogerson]

@williamtetlow Could you check that your production build is working correctly after adding that? This CacheProvider was originally part of the example until I saw it caused some issues.

[williamtetlow]

@ben-rogerson so the issue I was seeing was caused by tailwind class using the first-child selector and issue with that selector and emotion SSR.

I can't recreate the issue in example repo but implementation in the example repo _document is wrong and may be causing confusion.

To overcome issue with first-child selector you can use emotion advanced SSR setup to inline critical css in head instead of colocating <style> tags with components in body.

If you don't need to inline CSS in head you shouldn't include custom implementation of CacheProvider in _app and CriticalCSS in _document.

We should either

1. Update example repo to not have custom implementation in _document
2. Update it to use CacheProvider in _app
3. Have two examples - one with custom SSR and one without.

[ben-rogerson]

Hey william, I was wondering which option you would choose here?
Option 2 caused build issues last time it was part of the example.