Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/gatsbyjs/gatsby/discussions/28138 below:

SSR in Develop · gatsbyjs/gatsby · Discussion #28138 · GitHub

Nov 17, 2020 · 44 comments · 139 replies

-

This is an issue for discussing & reporting bugs for the upcoming SSR in development feature. The coming feature enables SSR in development so certain bugs that previously only show up in builds (like trying to access the window object) will now be seen during development which will help speed up fixing them.

Original PR: #27432
Original issue: #25729

Add the DEV_SSR flag to your gatsby-config.js:

module.exports = {
  flags: {
    DEV_SSR: true
  },
  plugins: [...]
}

If you've added custom webpack logic for the build-html stage e.g. to exclude a module from loading, you'll also need to add these rules for the develop-html stage.

exports.onCreateWebpackConfig = ({ stage, actions, plugins, loaders }) => {
  if (
    stage === "build-html" ||
    stage === "develop-html" ||
    stage === "develop"
  ) {
    actions.setWebpackConfig({
      module: {
        rules: [
          {
            test: /xterm|xterm-addon-fit/,
            use: loaders.null(),
          },
        ],
      },
    });
  }
};

Beta Was this translation helpful? Give feedback.

You must be logged in to vote

-

Beta Was this translation helpful? Give feedback.

You must be logged in to vote

1 reply

-

tested his site and code changes aren't applying cleanly so trigger a refresh of the page. Not sure if this is something goofy with HMR, his site, or dev ssr. I suspect one of the early as I couldn't reproduce it on another site.

Others — if HMR breaks on your site, let us know!

Beta Was this translation helpful? Give feedback.

-

Regarding lazy bundling, is it expected to work with the MDX plugin yet? Seems like the MDX plugin still eagerly builds everything when GATSBY_EXPERIMENTAL_DEVJS_LAZY is turned on.

Beta Was this translation helpful? Give feedback.

You must be logged in to vote

2 replies

-

Looks like you're in the wrong umbrella issue? But to answer your question — yes — MDX adds all of its code outside of pages so isn't affected by that. If you want to check out Query on Demand — that does help with most MDX setups #27620

Beta Was this translation helpful? Give feedback.

-

Hey everyone, I’m running into an issue that I’m fairly convinced is this issue (or related to SSR), but the additional debug features are not working on my end.

Context:

I’m building a website over at https://github.com/addisonschultz/Immaterial (immaterialcorp.com), and everything for the most part work and appears to be fine. The main issue I’m running into, is that when you navigate to certain pages from external links / navigating back from external links (immaterialcorp.com/cart OR immaterialcorp.com/product-name [this issue appears on all dynamically generated pages]), the CSS is not applied correctly.

Looking into this, it seems that the incorrect id is being applied to the Header element in this app, and it’s interesting that this does not happen on development, but only on production. I’ve been testing and trying to fix this locally by retriggering a build and serving this locally (scripted in this repo as yarn test-prod for debug purposes).

After looking into this, it seems directly related to:

• https://stackoverflow.com/questions/62945943/styles-disappear-on-page-reload-using-gatsbyjs-and-material-ui
• [Umbrella] Run SSR in Develop ☔  #25729
• and other posts regarding rehydration issues around styled-components, but I’m not using anything from styled so I’m ruling that out.

I was looking into this issue/PR, and was wondering if this experimental development build would help me figure out what was going on, but I’m not getting any logs, nor expected (incorrect css) behavior when running this (Again, my styles are only incorrect on prod).

I’m a bit confused at what I should try or do next. I’ve even hard coded the styles into css to see if a forced element style would help, but the wrong id and style are always applied (in the header on the pages mentioned above, they should be header-container and header-left respectively, see attached picture for reference). Again, this issue does NOT happen when I navigate to this page internally (gatsby-link, but only when loading this page directly from the source, or navigating back to the pages mentioned above from an external link).

Any help would be appreciated, even if it’s just help getting this dev feature working so I can debug more on my end. Thanks in advance!

Expected (dev):

Actual (prod / yarn test-prod) - (also notice additional injected elements/classnames):

Beta Was this translation helpful? Give feedback.

You must be logged in to vote

8 replies

-

No worries, and thanks for the update. I created a new branch upgrading gatsby to v2.30, but unfortunately I'm still getting the same exact result as the images and original comment.

I've made the branch here: https://github.com/addisonschultz/Immaterial/tree/upgrade/gatsby

Do you have any other suggestions on where I could start looking? I'm serving all of my css directly into the default layout component, and not importing or calling it from anywhere else, so that should be the only entry point for the styles

Beta Was this translation helpful? Give feedback.

-

did you add the DEV_SSR flag btw to your gatsby-config.js? That branch is gone now.

Beta Was this translation helpful? Give feedback.

-

diff --git a/gatsby-config.js b/gatsby-config.js
index 454c78b..2e3f74a 100644
--- a/gatsby-config.js
+++ b/gatsby-config.js
@@ -1,4 +1,7 @@
 module.exports = {
+  flags: {
+    DEV_SSR: true,
+  },
   siteMetadata: {
     title: `Immaterial`,
     description: `VINTAGE, CONSIGNMENT, ART & MUSIC.`,

My changes locally.

Can you list the steps to reproduce the bug you're seeing? Perhaps record a little video? Thanks for helping test!

Beta Was this translation helpful? Give feedback.

-

Hey Kyle, thanks again for helping me with this, hopefully this is helpful on your end as well.

Right now, I have everything on dev-ssr, and you can view it on my repo here.

As a quick overview, here's the situations where the styles are loading correctly and incorrectly:

NO ISSUES: yarn start (flag disabled)
NO ISSUES: yarn start (flag enabled)

ISSUES: yarn build && serve public(This skips the flag I believe)
ISSUES: Production (https://immaterialcorp.com) (See update below)

It loads the styles correctly only when navigating the site through gatsby-link and will show incorrect styles (most noticeable on index and /cart) when navigating directly to these endpoints.

I've made a video explaining some of the oddness that I'm experiencing:

https://www.dropbox.com/s/nbu56193n6c8u1e/bugs.mov?dl=0

Is there anything I should be looking for/at specifically? Many thanks in advance!

UPDATE 12/01/2021:
I've merged in a change outlined here that will rehydrate the page and serve the correct styles, but it's not the complete solution I was hoping for. I've updated the repository to include a branch dev-ssr that still faces these problems. Note as well that the prod version is not experiencing the issue anymore due to merging in this change, so you'll only be able to get into the odd state by running the repo locally.

Beta Was this translation helpful? Give feedback.

-

I'm using react-leaflet-geodesic in my site which unfortunately accesses window on load. I workaround the issue with this code fragment in my gatsby-node.js:

exports.onCreateWebpackConfig = ({ stage, loaders, actions }) => {
  if (stage === "build-html") {
    actions.setWebpackConfig({
      module: {
        rules: [
          {
            test: /react-leaflet-geodesic/,
            use: loaders.null(),
          },
        ],
      },
    })
  }
}

This does not work with SSR in develop. How do I work around that issue with SSR in develop?

Beta Was this translation helpful? Give feedback.

You must be logged in to vote

8 replies

-

hmm yeah odd indeed — endsWith should be work.

Beta Was this translation helpful? Give feedback.

-

Turns out it only worked randomly ... now it is back to the scrambled page in the upper screenshot. :/

Beta Was this translation helpful? Give feedback.

-

It's probably a separate problem not related to react-leaflet-geodesic, but the leaflet map in general ...

Beta Was this translation helpful? Give feedback.

-

I have a hydration bug that didn't show up in development even though I'm using DEV_SSR. The problem and solution are described here. In short, I was able to fix it by using a two-pass render with useEffect. But I'm wondering why the hydration bug didn't show up during development.

Beta Was this translation helpful? Give feedback.

You must be logged in to vote

3 replies

-

thank you for your excellent reproduction! Looking at it reminded me of this... very important TODO we forgot about haha

Beta Was this translation helpful? Give feedback.

-

Changing from render to hydrate then produces this error in the console

Beta Was this translation helpful? Give feedback.

-

Hello

We are struggling with css delivery when using DEV_SSR in the gatsby dev server together with gatsby-plugin-sass.

When DEV_SSR is enabled and we trigger a refresh in the browser we get this result:

where we expected this:

This also happens when we type in URLs and try to load these directly, but it seems like the css is delivered as expected every time when visiting / (and also works as expected when we navigate to the different pages client side).

We are using following versions of related packages:
"gatsby": "2.30.2" (@latest)
"gatsby-plugin-sass": "3.0.0" (@latest)
"sass": "1.32.2"
but I also experienced this issue with gatsby-plugin-sass 2.3.12 together with node-sass 4.14.1. Upgrading to latest gatsby-plugin-sass and dart-sass was an attempt at fixing the described problem.

Setting DEV_SSR: false in gatsby-config.js with a following restart of the dev server including a npm run clean solves the issue with the css delivery but we experience great benefits with SSR in development across our team!

Please let me know if you need more information or if I should submit a bug report!

Other than that, thank you for a great product and exciting features lately!

Edit:
Adding output from gatsby info here:

❯ ./node_modules/.bin/gatsby info --clipboard

  System:
    OS: macOS 11.1
    CPU: (12) x64 Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 14.15.3 - /usr/local/opt/node@14/bin/node
    npm: 6.14.9 - /usr/local/opt/node@14/bin/npm
  Languages:
    Python: 2.7.16 - /usr/bin/python
  Browsers:
    Chrome: 87.0.4280.141
    Edge: 87.0.664.75
    Firefox: 85.0
    Safari: 14.0.2
  npmPackages:
    gatsby: ^2.30.2 => 2.30.2
    gatsby-image: 2.4.19 => 2.4.19
    gatsby-plugin-google-analytics: 2.3.14 => 2.3.14
    gatsby-plugin-manifest: 2.4.28 => 2.4.28
    gatsby-plugin-netlify: 2.3.14 => 2.3.14
    gatsby-plugin-preload-fonts: 1.6.0 => 1.6.0
    gatsby-plugin-react-helmet: 3.3.10 => 3.3.10
    gatsby-plugin-react-svg: ^3.0.0 => 3.0.0
    gatsby-plugin-robots-txt: ^1.5.5 => 1.5.5
    gatsby-plugin-sass: ^3.0.0 => 3.0.0
    gatsby-plugin-sharp: ^2.12.1 => 2.12.1
    gatsby-plugin-sitemap: ^2.4.12 => 2.10.0
    gatsby-plugin-webpack-bundle-analyzer: 1.0.5 => 1.0.5
    gatsby-source-contentful: 3.1.1 => 3.1.1
    gatsby-transformer-sharp: ^2.10.1 => 2.10.1

Beta Was this translation helpful? Give feedback.

You must be logged in to vote

17 replies

-

I will test v2.31.0 when it is available..

DEV_SSR: true together with sass seems to work in gatsby@2.32.0-next.0. For me it seems that your changes is merged in that version @KyleAMathews.

Beta Was this translation helpful? Give feedback.

-

🙏 yup, the PR is in the next version (2.31.0 will be out today).

Thanks for testing and glad it resolved things (for your site at least)! Keep the bug reports coming.

Beta Was this translation helpful? Give feedback.

-

Seems to work seamlessly now. Used it throughout the day. Thank you for the quick solution! Now we're able to get the benefits from the dev-ssr which we believe can ease the onboarding of new developers to our gatsby project.

Beta Was this translation helpful? Give feedback.

-

I can't read the logs

My gatsby-config.js:

module.exports = {
  flags: {
    DEV_SSR: false
  },
  siteMetadata: {
    title: "Wordpress",
  },
  plugins: [
    {
      resolve: "gatsby-source-wordpress-experimental",
      options: {
        url: "http://localhost:8080",
      },
    },
    "gatsby-plugin-sharp",
    "gatsby-plugin-sitemap",
    "gatsby-plugin-offline",
    {
      resolve: "gatsby-plugin-manifest",
      options: {
        icon: "src/images/icon.png",
      },
    },
    "gatsby-transformer-sharp",
    {
      resolve: "gatsby-source-filesystem",
      options: {
        name: "images",
        path: "./src/images/",
      },
      __key: "images",
    },
  ],
};

info:

System:
    OS: Linux 5.8 Ubuntu 20.04.1 LTS (Focal Fossa)
    CPU: (4) x64 Intel(R) Xeon(R) CPU           E5430  @ 2.66GHz
    Shell: 5.0.17 - /bin/bash
  Binaries:
    Node: 12.13.1 - ~/.nvm/versions/node/v12.13.1/bin/node
    Yarn: 1.22.10 - ~/.nvm/versions/node/v12.13.1/bin/yarn
    npm: 6.12.1 - ~/.nvm/versions/node/v12.13.1/bin/npm
  Browsers:
    Chrome: 88.0.4324.96
    Firefox: 84.0.2
  npmPackages:
    gatsby: ^2.26.1 => 2.31.0
    gatsby-image: ^2.10.0 => 2.10.0
    gatsby-plugin-manifest: ^2.11.0 => 2.11.0
    gatsby-plugin-offline: ^3.9.0 => 3.9.0
    gatsby-plugin-sharp: ^2.13.0 => 2.13.0
    gatsby-plugin-sitemap: ^2.11.0 => 2.11.0
    gatsby-source-filesystem: ^2.10.0 => 2.10.0
    gatsby-source-wordpress-experimental: ^7.0.3 => 7.0.3
    gatsby-transformer-sharp: ^2.11.0 => 2.11.0

Beta Was this translation helpful? Give feedback.

You must be logged in to vote

3 replies

-

Can you open a new issue as it's not related directly to dev-ssr? This is a terminal rendering bug that's affecting a % of users but I haven't been able to reproduce. Perhaps, looking at your info, it's a linux thing? Getting all terminals to work the same is... challenging.

If you run GATSBY_LOGGER=yurnalist gatsby develop that should unstick you in the meantime.

Beta Was this translation helpful? Give feedback.

-

Yes, It's not related directly to dev-ssr, it's related to all flags. GATSBY_LOGGER=yurnalist gatsby develop and gatsby develop --no-color working now. My other gatsby project doesn't have this issue.

Beta Was this translation helpful? Give feedback.

-

This should be fixed on the latest versions — #29472

Beta Was this translation helpful? Give feedback.

-

Hi,

After going from Gatsby 2.29.3 to 2.31.1, source map seems to be gone even with DEV_SSR: false. Chrome DevTools now only shows webpack commons.js in Sources.

With flag DEV_SSR:false, the following reproduces the issue (yarn install + gatsby clean run between each case)

Source missing in Chrome:
package.json: "gatsby": "^2.24.67"
yarn list gatsby: gatsby@2.31.1

Source showing in Chrome
package.json: "gatsby": "<2.30"
yarn list gatsby: gatsby@2.29.3

package.json
"dependencies": {
"@chakra-ui/gatsby-plugin": "^1.0.0",
"@chakra-ui/icons": "^1.0.2",
"@chakra-ui/react": "^1.0.4",
"@emotion/react": "^11.1.2",
"@emotion/styled": "^11.0.0",
"framer-motion": "^3.1.1",
"gatsby": "^2.24.67",
"gatsby-plugin-web-font-loader": "^1.0.4",
"global": "^4.4.0",
"is-url-http": "^2.2.2",
"react": "^17.0.1",
"react-dom": "^17.0.1",
"react-icons": "^4.1.0",
},
"devDependencies": {
"gatsby-plugin-workerize-loader": "^1.5.0",
"prettier": "2.1.2",
"firebase-tools": "^9.2.1",
}

Any idea if related to this flag?

Beta Was this translation helpful? Give feedback.

You must be logged in to vote

5 replies

-

I suspect it's not related but it might be. Do you have a reproduction we could look at?

Beta Was this translation helpful? Give feedback.

-

Is this the source maps for Chakra or for your code? I do see source maps in the latest for code

Beta Was this translation helpful? Give feedback.

-

For my own code - writing some fairly JS-heavy pages as part of the site so need to be able to debug :)

Neither locally on the Mac or when opening a Chrome browser through codesandbox I see any source map with v2.30. How did you get that working? :)

Beta Was this translation helpful? Give feedback.

-

heh not sure. Source maps are weird sometimes IME and I never quite figure out why they stop working and why they come back.

Beta Was this translation helpful? Give feedback.

-

Found a corner case that is not caught by DEV_SSR but handled correctly by "gatsby build" (build failing):

I have a couple of worker threads that are compiled by webpack (with the help of "gatsby-plugin-workerize-loader").
If the worker code imports a library that is not present in package.json, "gatsby develop" fails silently and browser shows a blank page.

Beta Was this translation helpful? Give feedback.

You must be logged in to vote

1 reply

-

Oh interesting. Is there any console output in this case?

Beta Was this translation helpful? Give feedback.

-

On the condition of that my understanding of SSR in DEV together with fast reload enabled is correct: the SSR-generated version of a page will differ while doing the hydration process because the fast reload -"version" got a 'shadow-modal' that the SSR-version lacks. The discrepancy between these two versions generates a warning like the on screenshotted below.

Warning: Expected server HTML to contain a matching <span> in <div>.
    in span (at portal.js:38)
    in ShadowPortal (at indicator.js:41)
    in Indicator (at loading-indicator/index.js:29)
    in LoadingIndicatorEventHandler (at root.js:153)
    in ErrorBoundary (at fast-refresh-overlay/index.js:90)
    in FastRefreshOverlay (at root.js:142)
    in ConditionalFastRefreshOverlay (at root.js:149)
    in Unknown (at app.js:165)

This shadow-modal is needed to present compilation/linting/etc warnings and errors on an overlay in the browser, so I get why it's there. But to mute this warning I'm wondering if it would be a good idea to add the fast reload modal to the SSR-rendered version, only in dev mode while both DEV_SSR and FAST_REFRESH is enabled, so the the SSR and CSR version doesn't have this diff?

My motivation to suggest this is that I see we easily create diffs in the SSR and CSR output in our code base ourself, like when we conditionally determine things based on if we are on the server or in the browser (like accessing window/document) and return null instead of something useful. Because of this I would like the warning-output to be as clean as possible when everything is ok to not get too used to it and starting to ignoring these warnings.

Beta Was this translation helpful? Give feedback.

You must be logged in to vote

7 replies

-

[…] to delay rendering the dev overlays until after the first render

Sounds more pragmatic. Great👍

Beta Was this translation helpful? Give feedback.

-

So has this been fixed @KyleAMathews -- because I see this error on every page load.

index.js:2177 Warning: Expected server HTML to contain a matching <span> in <div>.
    in span (created by ShadowPortal)
    in ShadowPortal (created by Indicator)
    in Indicator (created by LoadingIndicatorEventHandler)
    in LoadingIndicatorEventHandler (created by _default)
    in ConditionalFastRefreshOverlay (created by _default)
    in _default

and I get a message saying:

info We're shipping new features! For final testing, we're
rolling them out first to a small % of Gatsby users
and your site was automatically chosen as one of them.

Beta Was this translation helpful? Give feedback.

-

Just got a fix merged into master #29692

master is now for upcoming v3 launch but I've marked it as one we can/should backport to v2 for release

Beta Was this translation helpful? Give feedback.

-

@KyleAMathews I've still got this issue even with gatsby 3.2.0. I'm using wrapPageElement to provide some barebones layout, it looks like following:

<main>
  <h1>Lovely Page Title</h1>
  <div>{page}</div>
</main>

Unfortunately the page is not generated for the server HTML (although a normal gatsby build will generate this correctly). Therefore when the content loads on the client side, the same warning is generated: Expected server HTML to contain a matching <div> in <main>.

Interestingly for "pages" it works correctly (no error message), for "templates", i.e. stuff that is created with createPage it doesn't work (error messages + missing DOM content from server).

Could that be the smoking gun?

Beta Was this translation helpful? Give feedback.

-

Intermittently get this white page error on local environment, only occurs with the new DEV_SSR enabled. seems related to gatsby-plugin-canonical-urls. occurs when visiting a route generated by gatsby-node createPage.

×
TypeError: Cannot read property 'getAttribute' of null
./node_modules/gatsby-plugin-canonical-urls/gatsby-browser.js.exports.onRouteUpdate
node_modules/gatsby-plugin-canonical-urls/gatsby-browser.js:13
  10 | }
  11 | 
  12 | var domElem = document.querySelector("link[rel='canonical']");
> 13 | var existingValue = domElem.getAttribute("href");
  14 | var baseProtocol = domElem.getAttribute("data-baseProtocol");
  15 | var baseHost = domElem.getAttribute("data-baseHost");
  16 | 
View compiled
(anonymous function)
/Users/Austin/Projects/CEGE/policy-scout/.cache/api-runner-browser.js:35
  32 | args.loadPage = loadPage
  33 | args.loadPageSync = loadPageSync
  34 | 
> 35 | const result = plugin.plugin[api](args, plugin.options)
  36 | if (result && argTransform) {
  37 |   args = argTransform({ args, result, plugin })
  38 | }
View compiled
./.cache/api-runner-browser.js.exports.apiRunner
/Users/Austin/Projects/CEGE/policy-scout/.cache/api-runner-browser.js:22
  19 |   }
  20 | }
  21 | 
> 22 | let results = plugins.map(plugin => {
  23 |   if (!plugin.plugin[api]) {
  24 |     return undefined
  25 |   }
View compiled
onRouteUpdate
/Users/Austin/Projects/CEGE/policy-scout/.cache/navigation.js:45
  42 | 
  43 | const onRouteUpdate = (location, prevLocation) => {
  44 |   if (!maybeRedirect(location.pathname)) {
> 45 |     apiRunner(`onRouteUpdate`, { location, prevLocation })
  46 |     if (
  47 |       process.env.GATSBY_EXPERIMENTAL_QUERY_ON_DEMAND &&
  48 |       process.env.GATSBY_QUERY_ON_DEMAND_LOADING_INDICATOR === `true`
View compiled
RouteUpdates.componentDidMount
/Users/Austin/Projects/CEGE/policy-scout/.cache/navigation.js:227
  224 | }
  225 | 
  226 | componentDidMount() {
> 227 |   onRouteUpdate(this.props.location, null)
  228 | }
  229 | 
  230 | shouldComponentUpdate(prevProps) {
View compiled
▶ 17 stack frames were collapsed.
(anonymous function)
/Users/Austin/Projects/CEGE/policy-scout/.cache/app.js:163
  160 |     dismissLoadingIndicator()
  161 |   }
  162 | 
> 163 |   renderer(<Root />, rootElement, () => {
  164 |     apiRunner(`onInitialClientRender`)
  165 |   })
  166 | })
View compiled

Beta Was this translation helpful? Give feedback.

You must be logged in to vote

2 replies

-

I can reproduce this when I don't have the siteUrl set in gatsby-config.js as an option for the plugin.

Beta Was this translation helpful? Give feedback.

-

I added a PR to validate this plugin's options #29688

Beta Was this translation helpful? Give feedback.

-

Beta Was this translation helpful? Give feedback.

You must be logged in to vote

3 replies

-

I'm getting the same warning.

Beta Was this translation helpful? Give feedback.

-

Same - easily reproducable on vanilla gatsby-starter-default

Beta Was this translation helpful? Give feedback.

-

This is a hydration bug with gatsby-image as the warning is correct, the server generated HTML is different than the client — given gatsby-plugin-image is replacing it soon, we can probably ignore this #27950

Beta Was this translation helpful? Give feedback.

-

Not sure if this is the right place to report but I'm consistently getting an error related to using the minified version of react when running in combination with vercel serverless functions. ie vercel dev command

Beta Was this translation helpful? Give feedback.

You must be logged in to vote

6 replies

-

That's correct. I run vercel dev locally. If you look at their documentation this is configured to run gatsby develop gatsby develop -p $PORT. Also after testing, If I disable the DEV_SSR flag, or if I simply run gatsby develop I don't get the error. Let me know if there is anything else I can do to help.

https://vercel.com/blog/vercel-dev#gatsby-and-node.js-functions

Beta Was this translation helpful? Give feedback.

-

Having exactly the same issue.. same screen with the same error... starting the devserver with gatsby develop as usual, and we have only one version of react installed

Beta Was this translation helpful? Give feedback.

-

hmm can't reproduce with vecel dev...

Beta Was this translation helpful? Give feedback.

-

ok reproduced it w/ a site w/ gatsby-plugin-mdx — are the rest of you using mdx as well?

Beta Was this translation helpful? Give feedback.

-

Actually I think it's just using hooks.

Anyways, this PR should fix things #29620

Beta Was this translation helpful? Give feedback.

-

Beta Was this translation helpful? Give feedback.

You must be logged in to vote

3 replies

-

I ended up disabling the feature by adding

flags: {
  DEV_SSR: false,
}

into gatsby-config.js.

I am not planning to add SSR to my project at this moment but if I were to do so, I prefer to catch errors on develop and not on build. I would've used this feature.

Beta Was this translation helpful? Give feedback.

-

This feature should only catch problems that'd prevent your site from building. Does gatsby build finish without errors.

Beta Was this translation helpful? Give feedback.

-

Yes, I do have it. Here is the output:

success Building HTML renderer - 9.463s
failed Building static HTML for pages - 0.942s

 ERROR #95312 

"localStorage" is not available during server side rendering.

See our docs page for more info on this error: https://gatsby.dev/debug-html


  14 |
  15 | export const isLoggedInVar = cache.makeVar<boolean>(
> 16 |   !!localStorage.getItem("token")
     |     ^
  17 | );
  18 |


  WebpackError: ReferenceError: localStorage is not defined

I guess I'll have to re-enable the flag and fix it

Beta Was this translation helpful? Give feedback.

-

This feature is the bee's knees. It's helped me avoid and diagnose a couple of nasty prod bugs already. ⭐

Beta Was this translation helpful? Give feedback.

You must be logged in to vote

0 replies

-

i found an issue related to this discussion with dev_ssr true. I resolved it, was from a timeout
The issue appear from large project using lot of code affecting webpack compilation speed

Have a look on
#31810 (comment)

Beta Was this translation helpful? Give feedback.

You must be logged in to vote

0 replies

-

I'm also getting this error

Warning: Expected server HTML to contain a matching <span> in <div>.
    in span (at portal.js:38)
    in ShadowPortal (at indicator.js:41)
    in Indicator (at loading-indicator/index.js:29)
    in LoadingIndicatorEventHandler (at root.js:153)
    in ErrorBoundary (at fast-refresh-overlay/index.js:90)
    in FastRefreshOverlay (at root.js:142)
    in ConditionalFastRefreshOverlay (at root.js:149)
    in Unknown (at app.js:165)

Beta Was this translation helpful? Give feedback.

You must be logged in to vote

0 replies

-

I just noticed that setting flags: { DEV_SSR: true } in gatsby-config is NOT enough: I also had to set GATSBY_EXPERIMENTAL_DEV_SSR=true environment variable to enable it.

Beta Was this translation helpful? Give feedback.

You must be logged in to vote

3 replies

-

I can confirm that I am on Gatsby 4.2.0 and with flags : { DEV_SSR: true } set in gatsby-config.js I get the warning

warn The following flag(s) found in your gatsby-config.js are not supported in your environment and will have no effect:
- DEV_SSR

However, if I set flags : { FAST_DEV: true } as I found mentioned in https://www.gatsbyjs.com/docs/reference/release-notes/v2.28/#feature-flags-in-gatsby-configjs, I get the following info output telling me that FAST_DEV is working, which supposedly includes DEV_SSR, QUERY_ON_DEMAND and LAZY_IMAGES (among other features) when enabled:

info The following flags are active:
- FAST_DEV · Enable all experiments aimed at improving develop server start time.
- PRESERVE_FILE_DOWNLOAD_CACHE · (Umbrella Issue (https://gatsby.dev/cache-clearing-feedback)) · Don't delete the downloaded files cache when changing gatsby-node.js & gatsby-config.js files.

There is one other flag available that you might be interested in:
- PARALLEL_SOURCING · EXPERIMENTAL · (Umbrella Issue (https://gatsby.dev/parallel-sourcing-feedback)) · Run all source plugins at the same time instead of serially. For sites with multiple source plugins, this can speedup sourcing and transforming
considerably.

Beta Was this translation helpful? Give feedback.

-

This leads me to wonder if FAST_DEV toggles the DEV_SSR flag at all. When I look at #28331 (comment) about use of the FAST_DEV flag in a previous version of Gatsby, the log output showed that DEV_SSR was being used, among others. In my case, I only see PRESERVE_FILE_DOWNLOAD_CACHE having been enabled by FAST_DEV.

When I add export GATSBY_EXPERIMENTAL_DEV_SSR=true to my .zshrc config file, it is not clear to me in the terminal log of gatsby develop if DEV_SSR is indeed taking effect.

Beta Was this translation helpful? Give feedback.

-

Last note here I promise. Even when having the environment variable set in my ZSH config and having it in my gatsby config, I still get this printed in the terminal when using Gatsby develop:

warn The following flag(s) found in your gatsby-config.js are not supported in your environment and will have no effect:
- DEV_SSR

@dko-slapdash , did you get some sort of confirmation in the console that DEV_SSR was indeed working for you?

Beta Was this translation helpful? Give feedback.

-

Is DEV_SSR still considered experimental? I thought it had been added, according to the recent docs. The issue was closed (not sure why, it's still a bug), but I still get the console error from the link component on aria-current:

react_devtools_backend.js:2560 Warning: Extra attributes from the server: aria-current

Issue #30750

Beta Was this translation helpful? Give feedback.

You must be logged in to vote

1 reply

-

i resolved this issue with aria-current mismatch from link with dev-ssr

to patch it's described here
#31996 (comment)

Beta Was this translation helpful? Give feedback.

-

Is there a way to have output CSS with dev-ssr enabled?

I see the html being rendered, but no css is emitted with my setup

Can we use loaders.miniCssExtract() when the stage is stage === 'develop-html' ?

Beta Was this translation helpful? Give feedback.

You must be logged in to vote

0 replies

-

when location.pathname rendered from Server is not ending by a trailing slash and window.location.pathname is ending by trailing slash from client it's result by aria-current mismatch from gatsby-link

Somebody should to check that. I did a patch to resolve this mismatch here
#31996 (comment)

Beta Was this translation helpful? Give feedback.

You must be logged in to vote

0 replies

-

Hi All
I've been automatically chosen to test the dev_ssr and so I'm submitting my feedback here as stated in terminal message.

I'm developing a new Gatsby theme and using yarn workspaces as dev environment.

I have been developing sites in Gatsby before and I must say it has been extremely frustrating to have dev_ssr on and a huge pain compared to not having it.

The main frustration is that whenever a change/mismatch big or small (sometimes very tiny) between the server and client occurs it just crashes and I have to create a new dev build. This sometimes happens if I just add/remove a console.log..
The most annoying part about it is that when the site crashes I get the following error message, which I can't use for anything. If the error was at least something more descriptive that I could use it would be awesome, but this is just annoying:

In the browser:
{"codeFrame":"No codeFrame could be generated","sourcePosition":null,"sourceContent":null}

in the terminal:
warn The path "/" errored during SSR.
Edit its component ../some-path to resolve the error.
__

The intention of giving the SSR errors right away without having to do builds to get them is awesome, but then the errors have to be descriptive or else they just slow down development a lot and are the cause of a lot of frustration.

I hope this is of some use to you.
Have a good day :)

Beta Was this translation helpful? Give feedback.

You must be logged in to vote

5 replies

-

Running into the exact same issue!

Beta Was this translation helpful? Give feedback.

-

Getting the same issue. Not sure how to solve it yet :(

Beta Was this translation helpful? Give feedback.

-

Getting the same issue. Not sure how to solve it yet :(

Yes. We in my team have seen this issue quite often lately (many times a day), compared to a couple of weeks ago. I have not been able to recognize if this is connected to changes in components used in wrapPageElement (which, in my perspective, would make more sense) or if it is connected to changes in general.

Beta Was this translation helpful? Give feedback.

-

While running gatsby develop, I got an error upon refreshing the page or trying to launch the site in a new tab or window.
This is what showed in my browser:
{"codeFrame":"No codeFrame could be generated","sourcePosition":null,"sourceContent":null}

I isolated the issue to the Helmet component from react-helmet.

I was using this code in a page template:
<Helmet bodyAttributes={{ style: "background-color: #f8f6f2;" }} />

I removed that component from my template and now I am able to refresh the page without getting the SSR error.

Beta Was this translation helpful? Give feedback.

-

Hi @iamkimchico, I faced something similar which was a pain as the error wasn’t descriptive enough to find where the error is coming from.

error: {"codeFrame":"No codeFrame could be generated","sourcePosition":null,"sourceContent":null}

fix: For me, I had to review my previous changes and I found that I had two graphql queries that had the same name which was conflicting, and updating that did the trick. Hope this helps ✌️

Beta Was this translation helpful? Give feedback.

-

Hey team, I just spun up a new Gatsby project and I got six staging features. I theme with Chakra-ui and after chasing a bug for a while I discovered it was the feature DEV_SSR that was causing the bug. The warning message from Chakra is;

Error Message

react_devtools_backend.js:2842 Warning: Prop `className` did not match. Server: "chakra-heading css-0" Client: "chakra-heading css-1gfmyfr"

gatsby-config.js

module.exports = {
// ..
  flags: {
    PARALLEL_SOURCING: true,
    LMDB_STORE: false,
    FAST_DEV: true,
    DEV_SSR: true,
    DEV_WEBPACK_CACHE: true,
    PRESERVE_FILE_DOWNLOAD_CACHE: false,
  },
// ...
}

package.json

//... 
"dependencies": {
    "@chakra-ui/icons": "^1.0.15",
    "@chakra-ui/react": "^1.6.6",
    "@emotion/react": "^11.4.1",
    "@emotion/styled": "^11.3.0",
    "@mdx-js/mdx": "^1.6.22",
    "@mdx-js/react": "^1.6.22",
    "framer-motion": "^4.1.17",
    "gatsby": "^3.11.1",
    "gatsby-plugin-image": "^1.12.0",
    "gatsby-plugin-layout": "^2.12.0",
    "gatsby-plugin-manifest": "^3.12.0",
    "gatsby-plugin-mdx": "^2.12.0",
    "gatsby-plugin-prettier-eslint": "^1.0.6",
    "gatsby-plugin-react-helmet": "^4.12.0",
    "gatsby-plugin-react-svg": "^3.0.1",
    "gatsby-plugin-sass": "^4.12.0",
    "gatsby-plugin-sharp": "^3.12.0",
    "gatsby-source-datocms": "^2.6.16",
    "gatsby-source-filesystem": "^3.12.0",
    "gatsby-transformer-sharp": "^3.12.0",
    "react": "^17.0.1",
    "react-dom": "^17.0.1",
    "react-helmet": "^6.1.0",
    "sass": "^1.38.0"
  },
  /...

gatsby-browser.js

import './src/assets/sass/_index.scss';

import { CSSReset, ChakraProvider } from '@chakra-ui/react';

import React from 'react';
const theme = extendTheme({
// ...
  fonts: {
    heading: "'Montserrat Alternates', 'Montserrat', sans-serif",
    body: 'Montserrat',
  },
// ...
});


export const wrapRootElement = ({ element }) => (
  <ChakraProvider theme={theme}>
    <CSSReset />

    {element}
  </ChakraProvider>
);

pages/index.js

import { Heading, Box } from '@chakra-ui/react';
import * as React from 'react';

// markup
const IndexPage = () => {
  return (
    <Box>
      <Heading as="h2" size="2xl">
        (2xl) In love with React & Next
      </Heading>
    </Box>
  );
};

export default IndexPage;

Thanks for all the hard work!

🙌 💪

Beta Was this translation helpful? Give feedback.

You must be logged in to vote

0 replies

-

Hi:
When saving the code in a project with gatsby on the frontend and strapi on the backend, I have to reload the page to see the changes. In theory, I should see the changes inmediatly after saving the component but this is not the case. I suspect that this problem comes from the gatsby-ssr file. How can I solve this issue?

I set to True the FAST_REFRESH flag but didn't work.

Thanks.

Beta Was this translation helpful? Give feedback.

You must be logged in to vote

0 replies

-

An issue I've experienced is that when DEV_SSR is enabled I get the warning of server/client mismatch.

Warning: Prop `className` did not match. Server: "sc-gGmKaI dbOXaI" Client: "sc-GqePz gTIRBz"

We have an in-house library built with styled components so I did suspect and rolled them back to a few versions to make sure it wasn't an issue there - which it wasn't. Turns out DEV_SSR was the culprit here. Setting this to false removes the warning though I'm still wary of it.

Beta Was this translation helpful? Give feedback.

You must be logged in to vote

0 replies

-

I'm having a lot of trouble in finding the cause of DEV_SSR bugs

It turns out that the page listed is not an issue and the .call error is even more obscure

Beta Was this translation helpful? Give feedback.

You must be logged in to vote

5 replies

-

after wrapping the gatsby cli in my own stderr and stdout i was able to get something:

Failed to validate error [Error [ValidationError]: "location.start.line" must be
 a number] {
  _original: {
    context: {
      sourceMessage: 'loadable: cannot find sidebar-sidebar-standard in stats
(from plugin: gatsby-plugin-loadable-components-ssr)'
    },
    filePath: 'src/pages/dev-404-page.tsx',
    location: { start: [Object] },
    text: 'There was an error while trying to load dev-404-page:\n' +
      'loadable: cannot find sidebar-sidebar-standard in stats (from plugin:
gatsby-plugin-loadable-components-ssr)',
    level: 'ERROR',
    category: 'SYSTEM',
    stack: [],
    docsUrl: 'https://gatsby.dev/issue-how-to',
    code: '11615'
  },
  details: [
    {
      message: '"location.start.line" must be a number',
      path: [Array],
      type: 'number.base',
      context: [Object]
    }
  ]
}

When using loadable and DEV_SSR, should we use hydrate?

https://www.gatsbyjs.com/plugins/gatsby-plugin-loadable-components-ssr/

module.exports = {
  plugins: [
    "gatsby-plugin-loadable-components-ssr",
    // OR
    {
      resolve: `gatsby-plugin-loadable-components-ssr`,
      options: {
        // Whether replaceHydrateFunction should call ReactDOM.hydrate or ReactDOM.render
        // Defaults to ReactDOM.render on develop and ReactDOM.hydrate on build
        useHydrate: true,
      },
    },
  ],
}

Beta Was this translation helpful? Give feedback.

-

After restarting gatsby, I'm also getting this

Generating development SSR bundle failed

No template for dependency: ProvidedDependency

File:.cache/caches/gatsby-plugin-mdx/mdx-scopes-dir/947a288a9631feed031f2416c3ad5e97.j
     s

Any idea?

Beta Was this translation helpful? Give feedback.

-

Update: I have disable all webpack cache with

export const onCreateWebpackConfigFunction: GatsbyNode['onCreateWebpackConfig'] = (
  { stage, rules, loaders, plugins, actions, getConfig, reporter, store },
  options
) => {
  const pluginOptions = options as unknown as GatsbyPluginTsCacheOptions;

  /**
   * Retrieve the initial gatsby webpack config
   */
  const config = getConfig() as Configuration;

  if (!config) {
    return void 0;
  }

  reporter.info(`[${pluginOptions.pluginName}]: replacing cache config`);

  /**
   * Replace the default caching strategy
   */
  config.cache = undefined;

  actions.replaceWebpackConfig(config);

And I no longer have crashes while refresh the page (with DEV_SSR enabled)

Beta Was this translation helpful? Give feedback.

-

Update: updating to gatsby-plugin-loadable-components-ssr v3.4.0 seemed to have helped

Beta Was this translation helpful? Give feedback.

-

How did you wrap the gatsby cli in your own stderr and stdout ?

Beta Was this translation helpful? Give feedback.

-

We've re-enabled DEV_SSR in Gatsby 4 again. You can use it (with the flag) with gatsby@next. You can also wait for the Gatsby 4.18 release (happening on 2022/07/05).

Beta Was this translation helpful? Give feedback.

You must be logged in to vote

1 reply

-

DEV_SSR Works great.. however when doing a build in gatsby@next I get

(note it works fine in 4.17)

success Building HTML renderer - 36.321s
success Execute page configs - 0.041s
failed Validating Rendering Engines - 1.484s

 ERROR #98001  WEBPACK

Built Rendering Engines failed validation failed validation.

Please open an issue with a reproduction at https://github.com/gatsbyjs/gatsby/issues/new for more help



  Error: Module parse failed: Unexpected token (393:27)
  File was processed with these loaders:
   * ./.yarn/cache/@vercel-webpack-asset-relocator-loader-npm-1.7.0-89d92b9b56-05f220859a.zip/node_modules/@vercel/webpack-asset-relocator-loader/dist/index.js
   * ./.yarn/__virtual__/babel-loader-virtual-b26b88a61a/0/cache/babel-loader-npm-8.2.3-855681b984-78e1e1a919.zip/node_modules/babel-loader/lib/index.js
  You may need an additional loader to handle the result of these loaders.
  |       await createPage({
  |         path,
  >         __webpack_require__.ab + "HomePage.tsx",
  |         context: {
  |           ref,
  
  - index.js:783056 Object.<anonymous>
    /workspace/octane/.cache/query-engine/index.js:783056:7
  
  - index.js:1011119 __webpack_require__
    /workspace/octane/.cache/query-engine/index.js:1011119:42
  
  - index.js:783027 Module.__webpack_require__.d.createResolvers
    /workspace/octane/.cache/query-engine/index.js:783027:80
  
  - index.js:1011119 __webpack_require__
    /workspace/octane/.cache/query-engine/index.js:1011119:42
  
  - index.js:356196 Module.__webpack_modules__.setActions.setActions
    /workspace/octane/.cache/query-engine/index.js:356196:70
  
  - index.js:1011119 __webpack_require__
    /workspace/octane/.cache/query-engine/index.js:1011119:42
  
  - index.js:1011253 
    /workspace/octane/.cache/query-engine/index.js:1011253:27
  
  - index.js:1011431 
    /workspace/octane/.cache/query-engine/index.js:1011431:3
  
  - index.js:1011436 Object.<anonymous>
    /workspace/octane/.cache/query-engine/index.js:1011436:12
  
  - loader:1099 Module._compile
    node:internal/modules/cjs/loader:1099:14
  
  - loader:1153 Object.Module._extensions..js
    node:internal/modules/cjs/loader:1153:10
  
  - .pnp.cjs:66483 Object.require$$0.Module._extensions..js
    /workspace/octane/.pnp.cjs:66483:33
  
  - loader:975 Module.load
    node:internal/modules/cjs/loader:975:32
  
  - .pnp.cjs:66323 originalModuleLoad
    /workspace/octane/.pnp.cjs:66323:14
  
  - child.ts:51 Function._module.default._load
    [gatsby-virtual-2de4be35d3]/[gatsby]/src/utils/validate-engines/child.ts:51:16
  
  - loader:999 Module.require
    node:internal/modules/cjs/loader:999:19
  

Beta Was this translation helpful? Give feedback.

-

I just upgraded to Gatsby 4.24 from 4.17, and I have to explicitly disable DEV_SSR because I'm always getting:

The server did not finish this Suspense boundary: The server used "renderToString" which does not support Suspense. If you intended for this Suspense boundary to render the fallback content on the server consider throwing an Error somewhere within the Suspense boundary. If you intended to have the server wait for the suspended component please switch to "renderToPipeableStream" which supports Suspense on the server

I believe this is the same error reported #36678 with a reproduction link

Beta Was this translation helpful? Give feedback.

You must be logged in to vote

0 replies

-

Like @phil-lgr I am having a lot of trouble finding the cause of errors during SSR in develop.

For example:

Failed to Server Render (SSR)
Error message:
React.Children.only expected to receive a single React element child.

File:
node_modules/@emotion/stylis/dist/stylis.esm.js:602:1

Stack:
WebpackError:  React.Children.only expected to receive a single React element child.
    at node_modules/@emotion/stylis/dist/stylis.esm.js:602:1
    at node_modules/styled-components/dist/styled-components.esm.js:1:13845

• These line numbers seem to be incorrect (that stylis line number points to variable assignment w = 1)
• Is there a way I can get any additional logging out of the gatsby-worker environment that this render step takes place in?

I'm fairly confident that the error is occurring in our component library, but have already sunk a few hours into trying to work out what this error in particular could be. Any suggestions for what to try next?

Beta Was this translation helpful? Give feedback.

You must be logged in to vote

4 replies

-

I am getting the same errors as @joerobot after upgrading to Gatsby 5.7 and find this impossible to debug. Reported line numbers and files seem to be random, and debugging Gatsby develop does not help because the renderHTML step is loaded off to a worker (which means breakpoints don't work).
Very unfortunate, because this feature would be really helpful for finding hydration errors after the React 18 Upgrade that comes along with Gatsby 5.

Beta Was this translation helpful? Give feedback.

-

I upgraded Gatsby from v4.17.2 to v 5.8.1 and got the exact same error message. This is 100% reproducible by closing all browser tabs, and restart development server with cache cleaned and SSR enabled.

Failed to Server Render (SSR)
Error message:
React.Children.only expected to receive a single React element child.

File:
node_modules/common-tags/es/index.js:41:32

Stack:
WebpackError:  React.Children.only expected to receive a single React element child.
    at node_modules/common-tags/es/index.js:41:32
    at node_modules/styled-components/dist/styled-components.esm.js:1:13862
    at node_modules/css-what/lib/es/parse.js:218:1
    at node_modules/css-what/lib/es/parse.js:291:1
    at node_modules/css-what/lib/es/stringify.js:70:1
    at node_modules/decode-uri-component/index.js:7:1
    at node_modules/css-what/lib/es/stringify.js:44:1

After spending couple of hours debugging the issue, I was able to locate the root cause, however I didn't have a solution yet.

If we try to add console.log(element) statement to wrapRootElement inside the gatsby-ssr.js of gatsby-plugin-styled-components, we will see a null is printed in the console. Further digging in to the problematic styled-components.esm.js:1:13862, we will see it is checking r.Children.only(e.children), where e has the following result (r is minified code, it points to React):

{
  sheet: e {
    options: { isServer: true, useCSSOMInjection: false },
    gs: {},
    names: Map(0) {},
    server: true
  },
  disableVendorPrefixes: false,
  children: null
}

The function definition of React.Children.only can be found at [here](https://github.com/facebook/react/blob/790ebc962de573a37e4755207eba91b07a0fa172/packages/react/src/ReactChildren.js#L3300, where it will perform throw new Error('React.Children.only expected to receive a single React element child.'); when children is null.

I didn't seems to experience null issue with gatsby build. So I am feeling it is a Gatsby SSR development specific issue where the documentation never mentioned when would element passed to wrapRootElement will become null.

Beta Was this translation helpful? Give feedback.

-

@just-small-potato I'm having the same issue, did you ever find a solution? Gatsby support seems to have gone silent.

Beta Was this translation helpful? Give feedback.

-

We are having the same issue

Beta Was this translation helpful? Give feedback.

-

I’m not sure if this is the right place to ask but how is there any documentation on how to render SSR pages in production? I have a custom node sever that serves built pages but how do I server SSR pages as gatsby develop does? Gatsby develop is not meant to run in prod, is it?

Beta Was this translation helpful? Give feedback.

You must be logged in to vote

0 replies

Converted from issue

This discussion was converted from issue #28138 on November 19, 2020 15:45.

Heading

Bold

Italic

Quote

Code

Link

Numbered list

Unordered list

Task list

Attach files

Mention

Reference

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4