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

Yandex crawler doesn't see styles in production mode #2038

Closed
them4g opened this Issue Sep 29, 2018 · 15 comments

Comments

Projects
None yet
6 participants
@them4g

them4g commented Sep 29, 2018

I have a problem with Yandex Webvisor. In production mode styled-components injects styles to CSSOM. Because of this yandex bot can't render page properly (it renders page as plain html without styles).

When I disabled speedy mode in production it helps. And I'm wondering if we can make this mode to be optional (e.g. check for FORCE_DISABLE_SPEEDY enviroment variable is set to true). I'll glad if you suggest better solution.

@probablyup

This comment has been minimized.

Contributor

probablyup commented Sep 29, 2018

An environment variable could work. It's been discussed before to give an option to disable speedy mode... I'm not opposed. @mxstbr @kitten @imbhargav5?

@dashed

This comment has been minimized.

dashed commented Oct 2, 2018

I'm also interested in a way to control DISABLE_SPEEDY thru an env variable for another usecase.

@mxstbr

This comment has been minimized.

Member

mxstbr commented Oct 3, 2018

What's your use case @dashed?


Are you sure that injecting the styles via slow mode will show up on Yandex @them4g, have you tried and verified that?

I'm not necessarily opposed to making this a configuration option, but I'd rather keep them to a minimum.

@probablyup

This comment has been minimized.

Contributor

probablyup commented Oct 4, 2018

If anyone knows a dev over at Yandex they should probably also just add support for CSSOM styles since the other CSS-in-JS libraries use the same set of APIs. I know some analytics tools have upgraded to detect them.

@probablyup

This comment has been minimized.

Contributor

probablyup commented Oct 8, 2018

If someone at Yandex sees this, this issue requires your crawler to make use of the CSSOM APIs: https://developer.mozilla.org/en-US/docs/Web/API/CSSStyleSheet

In production, we use insertRule which causes the CSS to only be accessible via document.styleSheets[0].cssRules etc

@probablyup

This comment has been minimized.

Contributor

probablyup commented Oct 10, 2018

@dashed

This comment has been minimized.

dashed commented Oct 16, 2018

What's your use case @dashed?

@mxstbr This would sound stupid; but a segregated environment to allow styles to be editable using DevTools.

@devrelm

This comment has been minimized.

Contributor

devrelm commented Oct 19, 2018

@mxstbr My company has another use-case: percy.io. I'd already mentioned this on another issue.

@probablyup's PR (#2089) is appreciated, but we'd rather not have to set up a separate build that sets that environment variable. Could an additional option be available where we could set a global variable to disable speedy? I would happily provide the PR.

Because the DISABLE_SPEEDY constant is set when styled-components is first loaded, we would need to set the global variable before loading our app. I had imagined something like the following for my company's use-case, which could easily set up a separate subdomain pointing to the exact same staging environment, but we could also check the user-agent string or use a number of other methods.

<!-- In our index.html -->
<script>window.SC_DISABLE_SPEEDY = /percy/.match(location.host)</script>
<script src="/app.min.js"></script>

The result would be 3 ways to disable speedy-styles:

  1. Disable automatically at build time in non-prod environments by referencing the NODE_ENV environment variable.
  2. Disable manually at build-time by setting the SC_DISABLE_SPEEDY environment variable.
  3. Disable manually just before it initializes at run-time by setting a SC_DISABLE_SPEEDY global variable before styled-components is initialized.
@probablyup

This comment has been minimized.

Contributor

probablyup commented Oct 19, 2018

@devrelm

This comment has been minimized.

Contributor

devrelm commented Oct 21, 2018

Hi @probablyup. This doesn't necessarily work for us. We already use the NODE_ENV flag to hide unreleased features. If we just used Percy against a dev build, we'd end up seeing features that aren't actually released yet.

Further, we use an artifact-based release pipeline, and would prefer to have the tested build be as close as possible to the build that makes it into prod.

@devrelm

This comment has been minimized.

Contributor

devrelm commented Nov 3, 2018

@probablyup Yeah, this definitely doesn't work for us. We're using Create React App, which doesn't allow NODE_ENV to be manually set. Any builds that actually produce distributable files will always have NODE_ENV=production.

@0leg5ergeev

This comment has been minimized.

0leg5ergeev commented Nov 7, 2018

Hi, I have the same problem on the topic in production mode on CRA, can you explain to me how you guys solved it?
Didn't find any documentation about DISABLE_SPEEDY

@devrelm

This comment has been minimized.

Contributor

devrelm commented Nov 8, 2018

@0leg5ergeev

As best as I can tell, there is no real solution for CRA apps, due to what I mentioned in my previous comment.

DISABLE_SPEEDY is the internal name for the constant that controls the optimization, so there wouldn't be any documentation about it. I have a PR in that provides a way to override it at runtime: #2185.

@devrelm

This comment has been minimized.

Contributor

devrelm commented Nov 13, 2018

@them4g as of v4.1.0, you should be able to set a SC_DISABLE_SPEEDY global variable before loading the styled-components library to disable the speedy optimizations.

See #2185 and the v4.1.0 changelog entry for more details.

@devrelm

This comment has been minimized.

Contributor

devrelm commented Nov 13, 2018

@0leg5ergeev ^^

@probablyup probablyup closed this Nov 13, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment