MFe apps should be handled with routes as much as possible. For example, don’t overuse an MFe within another MFe application. This way, the MFe apps don’t need to share the UI state.
The applications will always be created and destroyed when they share the same route. Therefore, you shouldn’t share UI states between MFe apps.
The single-SPA has categorized the MFe design into three parts, including:
Application
The application is the core building block of the MFe design. When it’s integrated with the root application, it will serve a specific purpose.
For example, the application may export public interfaces like components, UI state, value, parcel, or methods – and it must have its routes. It should also manage its lifecycle when it gets mounted, unmounted, and bootstrapped. These may also have interfaces that have to be imported by an MFe application.
Parcel
The parcel is like a web component. It does not have any routes and requires a custom lifecycle, which means the other application will have control when it gets to mount, unmount, and bootstrap.
The parcel is best suited when a UI feature needs to be shared across applications. The parcel can be small like a function or as big as an application.
Parcel-based MFe implementation is not recommended as it will require UI states to be shared between MFes, but it cannot be completely avoided. It is useful if the MFe applications are developing on different platforms.
The parcel may have its own deployment strategy with its own repository, or it can be a public interface of an application.
Utility
The utility applications have public interfaces. It doesn’t have any routes or UI to be rendered. Instead, it contains the logic that must be shared across the MFe applications.
The possible utilities that can be shared across MFes are:
The utilities may have separate deployment processes and repositories, such as applications and parcels. See here how these will appear when working together:
Home