[NextJS 14 Error] - Internal Error: do not use legacy react-dom/server APIs

[KryptonumDev]

Summary

I have a FaqSchema.js code to render Schema from Markdown as a schema.org:

import ReactMarkdown from 'react-markdown';
import { renderToStaticMarkup } from 'react-dom/server';

const SchemaFaq = ({ data }) => {
  const schama = {
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": data.map(({ question, answer }) => {
      return {
        "@type": "Question",
        "name": renderToStaticMarkup(<ReactMarkdown>{question}</ReactMarkdown>),
        "acceptedAnswer": {
          "@type": "Answer",
          "text": renderToStaticMarkup(<ReactMarkdown>{answer}</ReactMarkdown>)
        }
      };
    })
  }
  return (
    <script
      type="application/ld+json"
      dangerouslySetInnerHTML={{ __html: JSON.stringify(schama) }}
    />
  );
};

export default SchemaFaq;

Up to this point, the code was working properly, but in NextJS 14 I have an error. Error: Internal Error: do not use legacy react-dom/server APIs. If you encountered this error, please open an issue on the Next.js repo.

Additional information

No response

Example

No response

[icyJoseph]

If this is whole, within a server component, you could:

export default async function Home() {
  const { renderToString } = await import("react-dom/server");

  return (
      <div
        dangerouslySetInnerHTML={{
          __html: `${renderToString(<h1>Hello world 2</h1>)}`,
        }}
      />
  );
}

[KryptonumDev]

It doesn't work. It shows the same error: Error: Internal Error: do not use legacy react-dom/server APIs. If you encountered this error, please open an issue on the Next.js repo.

[jorroll]

In my case (Nextjs v14) I'm using renderToString inside a webhook endpoint and generating html markup for sending an email. Switching to a dynamic import (i.e. const { renderToString } = await import("react-dom/server");) fixed this issue. To state the obvious, you also need to remove the static import to make the error go away.

[Codename-404]

I am facing the same issue, but in react docs, this is not legacy. I have no idea why would they decide to make this kind of breaking change without any alternative.
Now we do what? Write plain html for every single component that we were rendering using renderToStaticMarkup?
And nobody is even responding to this thread.

[opeologist]

would love some guidance from the next team related to this 👀

[aitella]

I have the same issue with renderToString, we have to use renderToString for Google maps and now our pages are not working because of that issue.

[deebatedeployer]

Same here. Working perfectly on 13.5.x but now failing with Next 14.

            const contentString = ReactDOMServer.renderToString(
                <div>
                   ...
                </div>
            );

            sessionPolygons[sessionKey].setValues({ contentString });

Even replacing the renderToString with simple string manipulation fails.

            const contentString = `
            <div>
              ...${eval}
            </div>`;          

In this case, setting rendered HTML to polygons within Google Maps.

The only way I've got around this, and this is very annoying, is to use the "use client" component prefix. As the map is core functionality, a lot of the SSR value is now lost as a result.

[mamlzy]

yes after downgraded, it's working.

[Yf102]

Might be this will help https://react.dev/reference/react-dom/server/renderToString#alternatives

[nyxz]

From the reference that @Yf102 provided the following worked just fine for me:

Replace stuff like:

// 🚩 Unnecessary: using renderToString on the client
import { renderToString } from 'react-dom/server';

const html = renderToString(<MyIcon />);
console.log(html); // For example, "<svg>...</svg>"

with new react root:

import { createRoot } from 'react-dom/client';
import { flushSync } from 'react-dom';

const div = document.createElement('div');
const root = createRoot(div);
flushSync(() => {
  root.render(<MyIcon />);
});
console.log(div.innerHTML); // For example, "<svg>...</svg>"

Thanks @Yf102 !

[aitella]

Not sure using flushSync is a good workaround, from documentation:
Using flushSync is uncommon and can hurt the performance of your app. Use flushSync as last resort.

Also I'm getting this error with flushSync, in my case it's hard to avoid:
flushSync was called from inside a lifecycle method. React cannot flush when React is already rendering. Consider moving this call to a scheduler task or micro task.

This one works for me: #58533 (comment) But it's not very smooth with Google maps infowindows. So I didn't find a perfect alternative of renderToString unfortunately.

[danielegarciav]

Hey all, took a deep dive and found the cause of this (presumed) bug, and a workaround.

The cause

Next.js actually generates compiler aliases so that any references to "legacy" browser code in the react-dom/server module get rewritten to a "no-op" (which throws). Not completely sure why it's there.

(The "legacy" designation comes from React, not Next.js - basically all react-dom/server functions except renderToReadableStream are under "legacy".)

The workaround

We must bypass the alias. Rewrite your import to the following:

// import ReactDom from 'react-dom/server';
import ReactDom from 'next/dist/compiled/react-dom/cjs/react-dom-server-legacy.browser.development';

I simply used the path described by the compiler aliases script linked above.

To get TypeScript types on it:

declare module 'next/dist/compiled/react-dom/cjs/react-dom-server-legacy.browser.development' {
  import ReactDOMServer from 'react-dom/server';
  export = ReactDOMServer;
}

You can now use the renderToStaticMarkup function in the browser, even in Web Workers.

[danielegarciav]

It looks like the alias code was introduced by this PR, cc @shuding

Seems the PR doesn't take this use case into consideration.

[opeologist]

@shuding is there any update related to fixing this regression, or any internal conversations for communicating a path forward if those APIs are truly legacy ? thank you!

[ShahriarKh]

@danielegarciav I can't thank you enough 🏆
Just to note, I had to use next/dist/compiled/react-dom/cjs/react-dom-server-legacy.browser.production instead of ...development

[DOWSCZ]

amazing solution! after 6 hours of solving it i can use next 14 👍

[monsterooo]

zalify/easy-email-editor#372 What if it is some third-party library? 🐣

[yakovenkomax]

Check out a workaround I posted in another discussion:
#58533 (comment)

[GCinellu]

The workaround for me was to reintroduce the Pages Router, which is less than ideal.

I don't have direct control on the render call as it's been invoked by a third party library I'm using, making any attempt at overriding the call unsuccesful.

Since I didn't want to start monkey patching or go completing off course by opening PRs on foreign libraries, I tried by using the Pages Router and it worked.

Given that the migration path for when this will be fixed is quite straightforward, I am satisfied with what I have for now.

But let me repeat it, it's less than ideal.

[abdullah-hallaq]

Hey all, 👋 just dropping a quick note about my recent adventure with renderToString for Google Maps. It was a bit of a struggle – tried the flushAsync, but MUI styles were acting like divas, and the context wasn't really feeling the vibe.

My Workaround:

const YourComponent = ({ children }) => {
const devRef = useRef(null)

const options = useMemo(() => ({
    custom: true,
}), [devRef]);

const bindInfoWindow = useCallback(() => {
    const infoWindow = new ui.InfoWindow(options);
    currentGeometry && infoWindow.addTo(currentGeometry);
}, [options, currentGeometry]);

useEffect(() => {
    bindInfoWindow();
}, [currentGeometry, bindInfoWindow]);

return (
    <>
        <div style={{ display: "none" }}>
            <DefaultWindow ref={devRef}>{children}</DefaultWindow>
        </div>
    </>
);

};

And that did the job. If you're facing similar style tantrums from MUI and context not working (if needed), give this a shot. It's not fireworks, but it might just get the job done!