Error handling for remote module rendering in Module Federation.
Background
Remote module loading process may fail due to network resource loading failure or business logic rendering failure.
Though Module Federation Runtime provides detailed error log information and runtime hook to help users locate the cause of loading failure, we need to add error fallback mechanism to ensure the stability of the entire site, preventing the entire site from crashing due to the failure of a remote module rendering.
Solution
To build a robust remote module loading mechanism, we can handle possible problems from the following three levels:
The following solutions can refer to the examples in router-demo.
Network layer: Retry mechanism
Use @module-federation/retry-plugin plugin to handle network related issues:
-
Automatically retry failed resource requests
-
Configurable retry times and interval
-
Support custom error handling strategy
Loading layer: Error handling hook
Use Module Federation Runtime provided errorLoadRemote hook for more granular error handling:
- Capture errors in different loading lifecycle
- Provide fallback component or backup resource
- Support custom error handling strategy
Rendering layer: Error boundary
Use React's ErrorBoundary mechanism to handle component rendering exceptions:
- Graceful degradation, display friendly error prompts
- Isolate error impact, prevent the entire application from crashing
- Support error recovery and retry loading
These three solutions are for different scenarios, can be used separately, or combined to provide a more comprehensive error handling mechanism. Below we will introduce the specific implementation of each solution in detail.
Add retry mechanism
For weak network environment or producer has not started the service, we can add retry mechanism to request resources multiple times, which will increase the probability of resource loading success.
Module Federation official provides retry plugin @module-federation/retry-plugin to support retry mechanism for resources, support fetch and script resources retry.
Pure runtime registration
More about the parameter configuration of @module-federation/retry-plugin please see document
Plugin registration
Effect as follows:


errorLoadRemote hook
For errors in the loading process of remote modules, they can be captured in the errorLoadRemote hook.
errorLoadRemote is the hook for error handling in Module Federation Runtime. When the remote module loading fails, this hook will be triggered. It is designed to trigger when the module loading fails in different lifecycle stages, and allow users to customize error handling strategies.
errorLoadRemote supports returning a fallback component for error fallback, and also supports returning specific resource content to ensure subsequent processes render normally.
We divide the usage of module registration and loading into "pure runtime + dynamic import" and "plugin registration + synchronous import".
Pure runtime + dynamic import
When using pure runtime registration, the remote module will not request resources until after registration.
Use the errorLoadRemote hook to capture remote module loading errors (including resource loading errors), and support returning errorBoundary fallback component.
Effect as follows:


Plugin registration + synchronous import
Plugin registration supports using synchronous import to load modules, and the resource request timing is earlier than pure runtime, so we need to register the errorLoadRemote hook in the plugin.
The following example shows how to handle errors in different lifecycle stages.
If your application scenario is simple, you can refer to the simplified version below, which provides a unified error handling solution.
-
App.tsxsynchronous import:import Remote1App from 'remote1/app'; -
About
fallback.ts:-
errorLoadRemotehook receives anargsparameter, which contains the detailed information of the error. Throughargs.lifecyclewe can determine the stage of the error occurrence, and take the corresponding processing strategy: -
Handle component loading errors (
args.lifecycle === 'onLoad')- This type of error occurs in the module loading process other than the entry resource
mf-manifest.json - We can return a fallback component with styles:
- This type of error occurs in the module loading process other than the entry resource
-
Handle entry file loading errors (
args.lifecycle === 'afterResolve')- This type of error occurs in the entry resource
mf-manifest.jsonloading process, including network failures and manifest validation errors (e.g. missing required fields likemetaData,exposes, orshared) - We can handle it in the following two ways:
a. Try to load backup service:
b. Use local backup resource:
- This type of error occurs in the entry resource
-
Simplified version
If you don't need to distinguish between error types, you can also use a generic error handling solution:
-
Effect as follows:


Set ErrorBoundary for component
React's ErrorBoundary is the last line of defense for handling component-level errors, in the dynamic loading scenario of remote modules (such as lazy loading), it can help us capture and process the rendering errors of remote modules and provide graceful degradation.
Setting ErrorBoundary for components is suitable for dynamic import remote module scenarios, such as lazy loading scenarios.
Moreover, after setting ErrorBoundary for components, you can avoid relying on the errorLoadRemote hook for error fallback, which is a feature of React itself to provide error fallback for your components.
App.tsxdynamic import remote module
Effect as follows:

