Lu Nelson

👍 this is the first thing I tried; cause I need the babelify transforms... not working for me either

(please close)

Yes, off the top of my head the necessary operations for CSS-in-JS libs tend to be: - wrap the `` component with custom Providers which enable collection and critical extraction...

Examples from Gatsby—note: many only require a babel plugin for the client side, and only modify rendering for the SSR part - [emotion v11](https://github.com/emotion-js/emotion/tree/next/site/plugins/gatsby-plugin-emotion-next-compat) - [emotion v10](https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-plugin-emotion/src) - [styled components...

@slorber on closer examination, after trying to hack this today: I'm guessing when you said "it's not so easy" you might have been thinking about `react-loadable`...? This scheme doesn't seem...

@slorber yes functions for wrapping root and/or page element would also solve https://github.com/facebook/docusaurus/issues/2891. I see that you've indicated it as low-priority, but IMO it's rather important, e.g. for components or...

Thanks for the tips @slorber, good to know about those new components, but indeed yes the remounting-on-route-change problem remains open

@sawasawasawa yes I believe this is the essential problem with CSS-in-JS in docusaurus, that is the lack of server-side-rendering support. Normally in the SSR phase, CSS-in-JS rules should be collected...

@bennodev19 the solution requires an API to be made available from docusaurus, similar to Gatsby's `wrapRootElement` and `wrapPageElement` APIs, or Next.js' `_document.js` and `_app.js` APIs, that enable intervention at the...

I strongly encourage using xdm, it's a simpler, faster and more stable pipeline, it is always in sync with the remark/rehype ecosystem and its development is moving quickly