Emotion: Interoperability with other CSS in JS libraries

Created on 29 Jun 2017 · 16Comments · Source: emotion-js/emotion

Hello,

I'm not sure if it's currently an issue, but it's something to look at for sure.

It's a big blocker for adopting styled-components for me : https://github.com/styled-components/styled-components/issues/860

Source

jgoux

Most helpful comment

@TroutZen in production, emotion inject styles with speedy mode so no DOM element is created

thangngoc89 on 9 Aug 2017

👍2

All 16 comments

you could manually look for the style tag with a data-emotion attribute and move it around the head tag?

threepointone on 29 Jun 2017

This could be a great solution!

Do you think this should be implemented in userland or provide an API like insertion: 'first' | 'last' as an option in the babel plugin?

jgoux on 29 Jun 2017

I would bet money that they will be added in reverse order of how you import them.

tkh44 on 30 Jun 2017

I think userland is best bet for now. Mind you, for a large number of styles, we actually generate multiple stylesheets (over 65k), so this won't be bulletproof, but could be a good solution for now

threepointone on 30 Jun 2017

👍1

Thanks for the input, I'll try the style tag manipulation. 👍

jgoux on 1 Jul 2017

I'd like to revisit this issue if possible:

I have an application that uses some css resets (normalize) that would be nice to load first and have my opinionated stylings come last. Due to the low specificity of my overrides, load / cascade order takes precedence. The suggestion above to manipulate the DOM to rearrange the order, I'd prefer not to do because removing/appending will cause a repaint which is something that should be avoided in production quality apps.

I also tried inverting the declaration order per @tkh44, but that did not affect the order in the <head>

TroutZen on 9 Aug 2017

@TroutZen in production, emotion inject styles with speedy mode so no DOM element is created

thangngoc89 on 9 Aug 2017

👍2

@thangngoc89 A style element is still inserted in the DOM. It's just that insertRule is used so the rules themselves don't go through the DOM.

mitchellhamilton on 9 Aug 2017

@mitchellhamilton thank you for correcting me

thangngoc89 on 9 Aug 2017

@TroutZen the movement is a one time thing, you can avoid the repaint by doing it right before you start your application; ie - right after the application starts up, but before you start any rendering/insertion.

threepointone on 9 Aug 2017

frankly, not even sure you'll have a problem, since the tag will added only afterwards, and and your css resets are (presumably) included way before that via <link>/<style>.

threepointone on 9 Aug 2017

@threepointone - while this may be true (need to test) it doesn't obviate the need to have a consistent and declarative import order in both dev and production without the need for DOM manipulation (which feels a bit hacky to me).

TroutZen on 9 Aug 2017

Just want to add i'm running into the same issue as @TroutZen is describing above

sanpablomarket on 23 Aug 2017

👍1

Could this be reopened? I'm running into this same problem and I agree the current solution is somewhat hacky (to have to move the elements around in the head). I can move them around on the initial load of my add, but I have code split modules which are lazy loaded and their styles get appended to the end of the DOM when the modules load. I would love to see a similar feature to what JSS does where you can specify an insertion point using a comment or give it a node. This allows users to target shadow DOM and IFrames as well. (https://github.com/emotion-js/emotion/issues/388)