Allows listening to the startup progress of the platform.
In the host, when the platform starts, it fetches the manifests of the registered applications, among other things, and waits for the applications to signal their readiness, which can take some time.
You can subscribe to this Observable to provide feedback to the user about the progress of the platform startup. The Observable reports the progress as a percentage number. The Observable completes once the platform finished startup.
the current platform state.
Observable that, when subscribed, emits the current platform lifecycle state. It never completes and emits continuously when the platform enters another state.
Connects a micro application to the platform host.
The platform host checks whether the connecting micro application is qualified to connect, i.e., is registered in the host application under that origin; otherwise, the host will reject the connection attempt. Note that the micro application needs to be embedded as a direct or indirect child window of the host application window.
After the connection with the platform host is established, the micro application can interact with the host and other micro applications. Typically, the micro application connects to the platform host during bootstrapping. In Angular, for example, this can be done in an app initializer.
In the lifecycle of the platform, it traverses different lifecycle states that you can hook into by registering a callback to MicrofrontendPlatform.whenState.
Specifies the symbolic name of this micro application. The micro application must be registered in the platform host under this symbol.
Controls how to connect to the platform host.
A Promise that resolves once connected to the platform host, or that rejects otherwise.
Destroys this platform and releases resources allocated.
a Promise that resolves once the platformed stopped.
Checks whether this micro application is connected to the platform host.
Starts the platform in the host application.
The host application, sometimes also called the container application, provides the top-level integration container for microfrontends. Typically, it is the web application which the user loads into his browser that provides the main application shell, defining areas to embed microfrontends.
The platform should be started during bootstrapping of the host application. In Angular, for example, the platform is typically started in an app initializer.
In the host, the web applications are registered as micro applications. Registered micro applications can interact with the platform and other micro applications. As with micro applications, the host can provide a manifest to contribute behavior. For more information, see {@link MicrofrontendPlatformConfig.host.manifest}. If you are integrating the platform in a library, you may want to add behavior to the host's manifest, which you can do with a HostManifestInterceptor.
During platform startup, the platform loads the manifests of registered micro applications. Because starting the platform is an asynchronous operation, you should wait for the startup Promise to resolve before interacting with the platform. Optionally, you can subscribe to the platform’s startup progress to provide feedback to the user about the progress of the platform startup. See MicrofrontendPlatform.startupProgress$ for more information.
In the lifecycle of the platform, it traverses different lifecycle states that you can hook into by registering a callback to MicrofrontendPlatform.whenState. To hook into the startup of the platform, you can register an initializer using {@link Beans.registerInitializer}, optionally passing a runlevel to control when the initializer will execute. The platform supports following runlevels:
0, the platform fetches manifests of registered micro applications.1, the platform constructs eager beans and connects to the broker.2 and above, messaging is enabled. This is the default runlevel at which initializers execute if not specifying any runlevel.3, the platform installs activator microfrontends. See https://scion-microfrontend-platform-developer-guide.vercel.app/#chapter:activator to learn more about activators.Configures the platform and defines the micro applications running in the platform.
A Promise that resolves once platform startup completed.
Allows waiting for the platform to enter the specified PlatformState. If already in that state, the Promise resolves instantly.
the state to wait for.
A Promise that resolves when the platform enters the given state. If already in that state, the Promise resolves instantly.
Generated using TypeDoc
SCION Microfrontend Platform is a TypeScript-based open-source library that helps to implement a microfrontend architecture.
SCION Microfrontend Platform enables you to successfully implement a framework-agnostic microfrontend architecture using iframes. It provides you fundamental APIs for microfrontends to communicate with each other across origin, allows embedding microfrontends using a web component and enables routing between microfrontends. SCION Microfrontend Platform is a lightweight, web stack agnostic library that has no user-facing components and does not dictate any form of application structure.
You can continue using the frameworks you love since the platform integrates microfrontends via iframes. Iframes by nature provide maximum isolation and allow the integration of any web application without complex adaptation. The platform aims to shield developers from iframe specifics and the low-level messaging mechanism to focus instead on integrating microfrontends.
Cross-microfrontend communication
The platform adds a pub/sub layer on top of the native
postMessagemechanism to allow microfrontends to communicate with each other easily across origins. Communication comes in two flavors: topic-based and intent-based. Both models feature the request-response message exchange pattern, let you include message headers, and support message interception to implement cross-cutting messaging concerns.Topic-based messaging enables you to publish messages to multiple subscribers via a common topic. Intent-based communication focuses on controlled collaboration between applications. To collaborate, an application must express an intention. Manifesting intentions allows us to see dependencies between applications down to the functional level.
Microfrontend Integration and Routing
The platform makes it easy to integrate microfrontends through its router-outlet. The router-outlet is a web component that wraps an iframe. It solves many of the cumbersome quirks of iframes and helps to overcome iframe restrictions. For example, it can adapt its size to the preferred size of embedded content, supports keyboard event propagation and allows you to pass contextual data to embedded content. Using the router, you control which web content to display in an outlet. Multiple outlets can display different content, determined by different outlet names, all at the same time. Routing works across application boundaries and enables features such as persistent navigation.
A microfrontend architecture can be achieved in many different ways, each with its pros and cons. The SCION Microfrontend Platform uses the iframe approach primarily since iframes by nature provide the highest possible level of isolation through a separate browsing context. The microfrontend design approach is very tempting and has obvious advantages, especially for large-scale and long-lasting projects, most notably because we are observing an enormous dynamic in web frameworks. The SCION Microfrontend Platform provides you with the necessary tools to best support you in implementing such an architecture.
MessageClient
IntentClient
SciRouterOutletElement
OutletRouter
ContextService
PreferredSizeService
ManifestService
FocusMonitor
Activator