-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
[React 18] hydrateRoot(document, <RemixBrowser />) causes app crash with any scripts that modified DOM before hydration #2947
Comments
Note: Upgrading react-dom/react to v18 and changing hydrate to hydrateRoot is also affected by this bug. I've provided a test repo to use: https://github.com/hrgui/react-18-remix-app When doing the following changes: package.json: - "react": "^17.0.2",
+ "react": "^18.0.0",
- "react-dom": "^17.0.2",
+ "react-dom": "^18.0.0" entry.client.jsx: import { RemixBrowser } from "@remix-run/react";
- import { hydrate } from "react-dom";
+ import { hydrateRoot } from "react-dom/client";
- hydrate(<RemixBrowser />, document);
+ hydrateRoot(document, <RemixBrowser />); |
I deployed my first production remix app and have gotten consistent reports from users who have any extension that mutated the DOM (many many of them) I reverted to react 17, but this issue should be considered 'breaking'. We should probably retitle this issue to reflect that it's not just dark reader, but any extension that injects script tags or mutates the DOM. |
Having the same issue, and agree with @DAlperin for renaming this one |
Changed the title to reflect the true issue. This also applies for this tweet https://twitter.com/ebey_jacob/status/1509666902477402135. The app doesn't work until I disable apollo devtools / dark reader.
In my non-remix app, I had to do this fix: hrgui/nodejs-react-sc-demo@ac87234.
The question is, how do we make this work with hydrateRoot(document.body, <RemixBrowser />); ^ this doesn't crash, but it causes the app to fall back to client side rendering. This is because there is obviously a hydration mismatch - hydrateRoot(document.getElementById('root'), <RemixBrowser />); ^ this doesn't crash, but same issue - it causes the app to fall back to client side rendering. This is because there is obviously a hydration mismatch - hydrateRoot(document.getElementById('root'), <Outlet />); ^ This doesn't present any errors, but client-side hydration doesn't work as a simple counter does not seem to increment. |
The RemixBrowser API needs a new surface for this use case, I think. I can take a crack at a PR this week if I have time. It would be nice to hear from the core team on how they would like to approach this before I try anything though. |
Though, on second thought not being able to hydrate the <head> content would break a lot of things. So I'm not sure that this is the right tradeoff. |
Cross linking this: facebook/react#22833 |
I got reports that my remix site stopped working after update to React 18 from users with browser plugins which add Dark Reader: https://chrome.google.com/webstore/detail/dark-reader/eimadpbcbfnmbkopoojfekhnkhdbieeh Express VPN: https://chrome.google.com/webstore/detail/expressvpn-vpn-proxy-for/fgddmllnllkalaagkghckoinaemmogpe Does anyone know of a better workaround than reverting to React 17 until this issue is solved by either React or Remix team? |
* wait for remix-run/remix#2947 fix/workaround
This reverts commit a8d7f3f. Due to remix-run/remix#2947
I believe the React team will have a fix for this in the next release. The 18.2.0-next-a412d787e-20220518 release seems to address the underlying issue. |
@jacob-ebey I just created a codesandbox with 18.2.0-next-a412d787e-20220518 with the react SSR example. https://codesandbox.io/s/muddy-worker-t9g9ud It no longer crashes the application, which is good. However, the entire application still has to fallback to client-side rendering, which I believe may cause some unintended issues. In the app that I have above the application had fully rendered, then everything is rerendering when hydration kicks in. |
From my understanding, 18.2.0-next-a412d787e-20220518 contains the fix facebook/react#24523. The expectations set there is: yes, there will be hydration mismatches, but the client will fallback. In that case, the example in https://t9g9ud.sse.codesandbox.io/ is working as per the react team intended for now. As per reactjs/react.dev#4656 (comment), I believe the react team is working on a bigger plan to make this work on a more resilient way. |
Does React 18 allow Remix to create multiple roots for different parts of the document? If that were the case, a potential solution could be to have a |
If you upgrade to https://www.npmjs.com/package/react/v/18.2.0-next-a412d787e-20220518 you can do the following: In your
In your
And you should be streaming from the server again on the initial render. This is just a short-term hack; I pulled this from Kent Dodds's upcoming Front End Masters course, seems like an awesome one! |
React 18.2.0 is |
I would like to bump this issue, we have upgraded our stack to the latest version of react (18.2.0), we modified entry.server (https://github.com/remix-run/indie-stack/blob/main/app/entry.server.tsx) and entry.client (https://github.com/remix-run/indie-stack/blob/main/app/entry.client.tsx) inline with the latest version of the indie stack. After deploying to production, we are finding errors: If you would like to see a reproduction of the issue, please see here: https://pr-30-osc-academic-hub.fly.dev/ Obviously this diverges slightly from the original issue, as this screenshot demonstrates the error in incognito mode with no extensions installed. edit -> after doing some further investigation, we have pinpointed one of the extensions causing the issue (loom, screen recorder) |
I realice that the issue comes from the |
I have the same experience with @cjoecker when removing the <Script /> the message is disappeared |
That's because without |
@aaacafe786 It appears the
issue is a documented "gotcha" https://remix.run/docs/en/v1/pages/gotchas#browser-extensions-injecting-code With the solution being "Check out the page in incognito mode, the warning should disappear." @hrgui Should this issue be closed now (primary issue was fixed in react 18.2.0), and we can open a new issue to track the "gotcha"? |
Note that users can still use extensions in incognito if they desire (just need to check the checkbox) To be fair, it looks like the original problem has been solved as the application no longer crashes. However, the application resorts to client-side rendering as of React 18.2.0 in the case when an injection happens from an extension. @dr3 Is there a new issue already opened for the gotcha? Once that new issue is opened, then I don't mind closing this issue as solved and encouraging folks to move on to the gotcha issue. |
I have since found this comment from @kentcdodds where he says the issue isn't something that remix can fix. @hrgui I see you commented on this issue in the react repo which seems to be the same issue, so I think we can probably close this issue, and hope that this is fixed via the react issue |
Sounds good @dr3, I have closed this issue as completed. The original problem of an application crash has been fixed in React 18.2.0. Users that have chrome extensions that do inject into the DOM will encounter a client-side re-render warning. In Cypress it will be treated as an error since React uses error for that. Follow facebook/react#24430. I believe the only remaining action the Remix team could possibly do is not hydrate the entire document in order to fix the problem. Otherwise, we are waiting on facebook/react#24430. |
Store frontendAPI value on window as a fallback. This value can be used as a fallback during ClerkJS hot loading in case ClerkJS fails to find the "data-clerk-frontend-api" attribute on its script tag. This can happen when the DOM is altered completely during client rehydration. For example, in Remix with React 18 the document changes completely via `hydrateRoot(document)`. For more information refer to: - remix-run/remix#2947 - facebook/react#24430
Store frontendAPI value on window as a fallback. This value can be used as a fallback during ClerkJS hot loading in case ClerkJS fails to find the "data-clerk-frontend-api" attribute on its script tag. This can happen when the DOM is altered completely during client rehydration. For example, in Remix with React 18 the document changes completely via `hydrateRoot(document)`. For more information refer to: - remix-run/remix#2947 - facebook/react#24430
Hi, a dev from 2024, who also faced the same issue with Cloudflare Pages template. I tested it in a variety of configurations. Even with all the extensions disabled. As someone pointed out above (/previously closed thread) the core problem is with After trying a few React builds the following canary build solved the issue. This also worked with plugins like Grammarly, which we know changes the DOM before hydration. - "react": "^18.2.0",
- "react-dom": "^18.2.0"
+ "react": "19.0.0-canary-33a32441e9-20240418",
+ "react-dom": "19.0.0-canary-33a32441e9-20240418" I hope this will help out there anyone unstuck and continue to use the awsome features of Remix. |
Thanks a lot @iamvijaydev |
What version of Remix are you using?
the main branch of remix (hash a759aff)
Steps to Reproduce
Install the Dark Reader Chrome Extension: https://chrome.google.com/webstore/detail/dark-reader/eimadpbcbfnmbkopoojfekhnkhdbieeh?hl=en-US
yarn playground:new
yarn dev
in the newly created playground folder,yarn watch
in the root of remixExpected Behavior
should see Remix Playground, Sign up / Log In buttons with Dark Reader able to run
Actual Behavior
The playground loads for a sec, then when React does hydrateRoot, it fails to load if the Dark Reader Chrome Extension is enabled.
The workaround is to don't use any chrome extensions that modify the DOM in order to run the playground.
The text was updated successfully, but these errors were encountered: