Cannot turn off "potentially unsafe when doing server-side rendering" noise

[RoystonS]

Emotion 10 is emitting a series of console warnings along the lines of:

The pseudo class ":first-child" is potentially unsafe when doing server-side rendering. Try changing it to "first-of-type"
The pseudo class ":nth-child" is potentially unsafe when doing server-side rendering. Try changing it to "nth-of-type"

• emotion version: 10.0.4
• react version: 16.7.0-alpha2

Problem description:

1. I'm not using server-side rendering so these warnings aren't useful for me and are just console noise that means real problems will be masked. Apart from running in a production build, I can't see any way to turn these warnings off right now.
2. The error message doesn't help me understand why these pseudo classes are a problem; I can't find them mentioned in the Emotion docs, or references on the Internet as to why these might be a problem.

Suggested solution:

1. Provide a way to turn off these warnings if users don't want them.
2. Provide a link, or some documentation, as to why these pseudos are problematic.

[Andarist]

Leaving this here - #1059 (comment) as this issue is dedicated to this problem.

[vajkri]

We are getting the warnings too using SSR.
The styles targeting with :nth-child(), :first-child or :last-child don't even get applied server-side, so this causes elements to "jump" on page load when these styles get applied client-side.

[brentertz]

Hi Folks,

The inability to disable these console messages is a blocker for us being able to ship the Emotion 10 update to our component library. As a library, these messages are also visible to all of our downstream consumers.

We do not wish to update the selector usage in our library as we do not believe Emotion's current SSR strategy to be a valid trade-off for breaking numerous commonly used CSS selectors, hence #1178. We are hopeful that an alternate approach can be found there as well, but in the mean time, simply would like to disable these console messages.

Is there anything that can be done here to move things forward? We are willing to do the work, or collaborate, if you can provide some insight into the direction that you would like to take.

Possible Solutions

• Simply remove logging; instead improve and rely on SSR documentation
• Conditionally remove logging, e.g. ENV var or other opt out mechanism
• Only log when server side rendering
• Only log message once per page load
  • Unsure if this would avoid excess logging during unit tests though
• Remove the Stylis “linting” plugins from the default cache implementation and make them opt-in
• Use linter/stylelint instead
  • Rules then become user configurable as ignored, warning, or error
  • Create and document a stylelint-config-emotion package
• Adjust the Stylis "linting" plugin to support a special style property that allows the message to be suppressed. See PR [cache] Add ignore flag for the unreliable selectors warning #1209

Additional Considerations

• Our product is an open-source component library, as opposed to an application, so preferably any solution will not place an additional configuration burden on downstream consumers.

Lastly, thank you for all of your efforts in creating and maintaining this project, which solves a lot of our problems!

[brentertz]

@Andarist Do you have any thoughts on my comments above?

[Andarist]

Well, personally I think the story around this has to be improved somehow. There is somewhat more fresh discussion around this here. Could you take a look there and comment what do you think about stuff mentioned there?

[brentertz]

Hi @Andarist Thank you for your attention.

I am aware of that issue and even link to it in my comments above. I'd be happy to comment on it further following this message. For full transparency, @kylegach and I work together.

Whilst Emotion's SSR implementation is certainly at the heart of this issue, I would imagine that is a bigger issue to resolve and I did not want to presume that you would be open to making changes in that area.

In the mean time, I believe that finding a way to resolve this issue would provide immediate value to many Emotion users, particularly those affected that aren't even doing SSR. I understand not wanting to put a lot of work into it if changing the underlying implementation could just make this issue go away, but what if it could be resolved with minimal effort and minimal impact?

I recently added another possible solution to the list in my comment above, which feels pretty lightweight. I'll reiterate it here.

• Adjust the Stylis "linting" plugin to support a special style property that allows the message to be suppressed. See PR [cache] Add ignore flag for the unreliable selectors warning #1209

[Andarist]

Unfortunately this is tightly coupled to SSR concerns - especially for your use case. From what I understand you develop a UI library which uses emotion and ideally your consumers shouldn't be aware of emotion and they should be able to do SSR without suffering the FOUC.

[brentertz]

I agree that this issue should ideally be solved by altering Emotion's SSR implementation to not “break” standard CSS, but I don’t believe that issue will be resolved in as timely a manner as this one may be mitigated. Again, I think #1209 resolves the issue quite minimally.