Upstream remoteEntry.js updates with 'react-18-ssr' architecture throws errors

[andrewstec]

Is the React-18-ssr architecture intended to adapt to changing upstream remoteEntry.js files? I tried this architecture and when my upstream app reloaded, I had trouble refreshing the SSR application to perform a re-render and therefore the rehydration threw an error:

Error
Text content does not match server-rendered HTML.
Call Stack
 checkForUnmatchedText
  remoteEntry.js:10736:11
 didNotMatchHydratedTextInstance
  remoteEntry.js:12483:5
 prepareToHydrateHostTextInstance
  remoteEntry.js:13695:13

It looks like there will be errors when an upstream application changes unless the SSR application is restarted. I tried to remove the App from the module cache to workaround this issue when a change is detected. In a production environment, it would be necessary to avoid the "Text content does not match server-rendered HTML." The remotes would not be in the same container and there would be synchronization issues that result in this error appearing in production.

This example seems robust except for this potential issue. I have looked for a graceful runtime fix but could this be a limitation to the architecture?

[ScriptedAlchemy]

you need to clear require cache when remote changes. likely no example of that here, but module-federation/node package has the utils

[andrewstec]

you need to clear require cache when remote changes. likely no example of that here, but module-federation/node package has the utils

Thanks @ScriptedAlchemy . I have been looking at your module-federation/node repo and issues for the logic to get express require cache completely cleared and restored using the revalidate() function your utility exposes in module-federation/node.

module-federation/core#397 (comment)

I will update you there, but thank you for answering. I see all the repos you contribute to in this area. Thank you so much!

[ScriptedAlchemy]

Yeah for express you need to clear the route stack, the node readme has a section on clearing express route stack cache

[ScriptedAlchemy]

We are also working on fast refresh and HMR support, this should useable in production node too, so we can use webpack effecent HMR in prod servers to elegantly replace modules as they are updated instead of the nuclear option of wiping the require cache

[andrewstec]

We are also working on fast refresh and HMR support, this should useable in production node too, so we can use webpack effecent HMR in prod servers to elegantly replace modules as they are updated instead of the nuclear option of wiping the require cache

That sounds amazing. Is there something on a roadmap that I can track? I will keep my eyes open!