sp-dev-docs icon indicating copy to clipboard operation
sp-dev-docs copied to clipboard

Error using react-dom/server function renderToString

Open lennertcc opened this issue 4 years ago • 10 comments

Target SharePoint environment

SharePoint Online

What SharePoint development model, framework, SDK or API is this about?

💥 SharePoint Framework

Developer environment

Windows

What browser(s) / client(s) have you tested

  • [ ] 💥 Internet Explorer
  • [X] 💥 Microsoft Edge
  • [ ] 💥 Google Chrome
  • [ ] 💥 FireFox
  • [ ] 💥 Safari
  • [ ] mobile (iOS/iPadOS)
  • [ ] mobile (Android)
  • [ ] not applicable
  • [ ] other (enter in the "Additional environment details" area below)

Additional environment details

  • browser version Versie 90.0.818.66 (Officiële build) (64-bits)

  • SPFx version 1.10.0

  • Node.js version v10.22.0

Describe the bug / error

When using import { renderToString } from 'react-dom/server';

and running gulp serve

the call to const stringElement = renderToString(<SomeReactComponent key={index} />)

runs into

react-dom-server.browser.development.js:2543 
Uncaught TypeError: Cannot read property 'getCurrentStack' of undefined
    at pushCurrentDebugStack (react-dom-server.browser.development.js:2543)
    at ReactDOMServerRenderer.read (react-dom-server.browser.development.js:3138)
    at renderToString (react-dom-server.browser.development.js:3628)
    at MySPFxReactComponent.tsx:204

Steps to reproduce

See bug description

Expected behavior

When packaging the solution and using it from the App Catalog, this error does not occur and the renderToString function works as expected.

lennertcc avatar May 25 '21 12:05 lennertcc

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

ghost avatar May 25 '21 12:05 ghost

I'm on SPFx 1.11.0 and having the same error trying to use renderToStaticMarkup from react-dom/server.

image

c-eiser13 avatar Jun 01 '21 16:06 c-eiser13

@lennertcc @c-eiser13 - sorry for the long delay. Just to clarify - were you experiencing this error when debugging using local workbench?

AJIXuMuK avatar Dec 29 '21 19:12 AJIXuMuK

No, I've always worked with debugging on actual SharePoint Online pages using ?loadSPFX=true&debugManifestsFile=https://localhost:4321/temp/manifests.js or something similar

Thanks for working on this!

lennertcc avatar Dec 29 '21 21:12 lennertcc

@AJIXuMuK se here, happens to me when running debugger against an actual site, I do not use local workbench. Thanks!

c-eiser13 avatar Dec 29 '21 21:12 c-eiser13

Thank you @lennertcc, @c-eiser13 for the quick response. So the problem here is we always load production versions of react and react-dom. But when you reference react-dom/server in dev mode - it will load dev version. And that leads to the error.

We're discussing potential ways of loading development versions of react as it also could be beneficial for profiling (as discussed in #6548). But currently there are no ETAs for that.

As a workaround I can propose the next solution.

  1. change your import to use react-dom/server.browser as this is the correct module to reference client-side.
  2. Add additional processing in gulpfile.ls to always load production build:
if (process.env.NODE_ENV !== 'production') {
  let reactDomServerContent = '';

  build.rig.addPreBuildTask({
    name: 'react-dom-server-prebuild',
    execute: async () => {
      try {
        reactDomServerContent = fs.readFileSync('./node_modules/react-dom/server.browser.js', 'utf8');
        fs.writeFileSync('./node_modules/react-dom/server.browser.js',
          `'use strict';
    module.exports = require('./cjs/react-dom-server.browser.production.min.js');
    `);
      } catch (e) {
        console.log(e);
      }
    }
  });

  build.rig.addPostBundleTask({
    name: 'react-dom-server-postbuild',
    execute: async () => {
      fs.writeFileSync('./node_modules/react-dom/server.browser.js', reactDomServerContent);
    }
  });
}

AJIXuMuK avatar Dec 30 '21 17:12 AJIXuMuK

Thank you @lennertcc, @c-eiser13 for the quick response. So the problem here is we always load production versions of react and react-dom. But when you reference react-dom/server in dev mode - it will load dev version. And that leads to the error.

We're discussing potential ways of loading development versions of react as it also could be beneficial for profiling (as discussed in #6548). But currently there are no ETAs for that.

As a workaround I can propose the next solution.

  1. change your import to use react-dom/server.browser as this is the correct module to reference client-side.
  2. Add additional processing in gulpfile.ls to always load production build:
if (process.env.NODE_ENV !== 'production') {
  let reactDomServerContent = '';

  build.rig.addPreBuildTask({
    name: 'react-dom-server-prebuild',
    execute: async () => {
      try {
        reactDomServerContent = fs.readFileSync('./node_modules/react-dom/server.browser.js', 'utf8');
        fs.writeFileSync('./node_modules/react-dom/server.browser.js',
          `'use strict';
    module.exports = require('./cjs/react-dom-server.browser.production.min.js');
    `);
      } catch (e) {
        console.log(e);
      }
    }
  });

  build.rig.addPostBundleTask({
    name: 'react-dom-server-postbuild',
    execute: async () => {
      fs.writeFileSync('./node_modules/react-dom/server.browser.js', reactDomServerContent);
    }
  });
}

Thank you for the workaround. I applied it, but it's still not working for me. Is there any news regarding this issue? Are there checks I should run for this workaround to work properly? Loading the solution to the app catalog every time is rather time consuming, as well as using the local workbench only

CocoYubari avatar Mar 31 '22 08:03 CocoYubari

@CocoYubari you might need to add const fs = require("fs"); to the top section of the file, under const build = require('@microsoft/sp-build-web');

HiltonGiesenow avatar Apr 10 '22 15:04 HiltonGiesenow

@HiltonGiesenow turned out I put that line in the wrong place, thank you!

CocoYubari avatar Apr 11 '22 15:04 CocoYubari

Thank you @lennertcc, @c-eiser13 for the quick response. So the problem here is we always load production versions of react and react-dom. But when you reference react-dom/server in dev mode - it will load dev version. And that leads to the error.

We're discussing potential ways of loading development versions of react as it also could be beneficial for profiling (as discussed in #6548). But currently there are no ETAs for that.

As a workaround I can propose the next solution.

  1. change your import to use react-dom/server.browser as this is the correct module to reference client-side.
  2. Add additional processing in gulpfile.ls to always load production build:
if (process.env.NODE_ENV !== 'production') {
  let reactDomServerContent = '';

  build.rig.addPreBuildTask({
    name: 'react-dom-server-prebuild',
    execute: async () => {
      try {
        reactDomServerContent = fs.readFileSync('./node_modules/react-dom/server.browser.js', 'utf8');
        fs.writeFileSync('./node_modules/react-dom/server.browser.js',
          `'use strict';
    module.exports = require('./cjs/react-dom-server.browser.production.min.js');
    `);
      } catch (e) {
        console.log(e);
      }
    }
  });

  build.rig.addPostBundleTask({
    name: 'react-dom-server-postbuild',
    execute: async () => {
      fs.writeFileSync('./node_modules/react-dom/server.browser.js', reactDomServerContent);
    }
  });
}

in 2024, this workaround is still working for me when needing to use renderToString.

Instead of import { ... } from 'react-dom/server.browser I have to use import { ... } from 'react-dom/server' in the respective file. Don't forget to add const fs = require("fs"); in the gulpfile as mentioned by @HiltonGiesenow

SPFx: 1.18.2 Node: v18.18.0 React/Dom: 17.0.1

Cheers!

bradleypregon avatar Feb 15 '24 17:02 bradleypregon

Thank you for taking the time to file an issue. We periodically archive older or inactive issues as part of our issue management process, which automatically closes them once they are archived.

If you’d like to understand more about why and how we handle archived (closed) issues, please see Our approach to closed issues.

We appreciate your contribution and if this is still an active issue with the latest SPFx versions, please do resubmit the details. We needed to perform a cleanup, so that we can start with a clean table with a new process. We apologize for the inconvenience this might cause.

github-actions[bot] avatar May 02 '25 15:05 github-actions[bot]