React module federation gives __federation_shared_react-dom-6fc2ee8d.js:224 TypeError: Cannot read properties of null (reading 'useContext') at react_production_min.useContext (__federation_shared_react-af90d75c.js:59:144)

[Elvis116]

React module federation gives __federation_shared_react-dom-6fc2ee8d.js:224 TypeError: Cannot read properties of null (reading 'useContext') at react_production_min.useContext (__federation_shared_react-af90d75c.js:59:144)
Is it due to the removal of singleton option in shared?

[Elvis116]

To reproduce create a component based on @mui/x-date-pickers on remote project.

[Elvis116]

The root component might be @mui/material/Popper. Can anyone help check it? Thanks.

[Elvis116]

After further digging, it is caused by @mui/system/useThemeWithoutDefault. Not sure how to solve it in vite federation plugin, webpack module federation works fine.

[FrancicoVerdu]

Hi, I think your error is repeated Issue 294. When I have had the same problem I have solved it by adding to the host component the dependencies of the remote component, this is not an optimal solution but it can get you out of trouble.

[nahimr]

The root component might be @mui/material/Popper. Can anyone help check it? Thanks.

Same problem here, it looks like it's using useTheme that relies on useContext, also @originjs doesn't allow singleton shared dependencies. Which makes this library useless for big project.

[DawiePritchard]

I cannot stress enough how critical managing dependency versions is when using this plugin, especially when dealing with singleton patterns like React's context.

Recently, I encountered issues related to context API failures in a federated module which was indirectly caused by mismatched library versions. It turns out, the root cause was related to how versions were specified in package.json.

For instance, specifying a dependency version with a caret (^), such as react-router-dom:"^6.8.2", allows npm to install minor updates automatically. This can lead to scenarios where your lockfile points to a newer version than you explicitly tested with, like 6.23.0 in this case. Here’s what you might see in your yarn.lock or package-lock.json:

react-router-dom@^6.8.2:
  version "6.23.0"

This scenario highlights the importance of using exact versions in federated modules or at least being very deliberate about version ranges. In a federated environment, unexpected updates can lead to incompatibilities, especially if different versions of the same package end up being loaded in the host and remote apps.

A safer approach could be to remove the caret (^) and pin the dependencies to exact versions to prevent such issues in both your host and remote apps:

"react-router-dom": "6.8.2"

This ensures that all instances of the application, across different federated modules, use exactly the same version, reducing the risk of runtime errors due to version mismatches.

While this might reduce flexibility in quickly receiving updates, it adds a layer of reliability and predictability to your build and deployment processes in a federated architecture.

Hope this helps anyone struggling with similar issues, if anyone has any alternative solutions please let me know!

The plugin should ideally manage these dependencies more effectively, especially as the number of federated apps grows, making manual dependency management increasingly complex which is not an ideal scenario.