PoC: resolve a promise once all remote bundles are initialized - #59
Draft
petschki wants to merge 1 commit into
Draft
PoC: resolve a promise once all remote bundles are initialized#59petschki wants to merge 1 commit into
petschki wants to merge 1 commit into
Conversation
…e initialized
The document-ready handler started the initialization of all Module
Federation remote bundles but did not wait for them: the
``patternslib__mf--loaded`` event fired before any remote had actually
loaded and run its main module. Consumers had no way to know when the
remotes' patterns and components were registered.
The helper now initializes all remotes in parallel, waits for all of
them to settle (a failing remote is logged and does not block the
others), and only then dispatches the event. The new promise
``window.__patternslib_mf_initialized`` is created at module load time,
so it can be awaited by code running before or after document ready —
the Patternslib registry uses it to defer the initial DOM scan.
A remote's main module usually only does ``import("./bundle")`` — the
async boundary needed to consume shared modules — and the registrations
happen in that chunk. If the main module exports that promise as its
default export (``export default import("./bundle")``), the helper
waits for it as well. Remotes without the export keep working as
before.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The document-ready handler started the initialization of all Module Federation remote bundles but did not wait for them: the
patternslib__mf--loadedevent fired before any remote had actually loaded and run its main module. Consumers had no way to know when the remotes' patterns and components were registered.The helper now initializes all remotes in parallel, waits for all of them to settle (a failing remote is logged and does not block the others), and only then dispatches the event. The new promise
window.__patternslib_mf_initializedis created at module load time, so it can be awaited by code running before or after document ready — the Patternslib registry uses it to defer the initial DOM scan.A remote's main module usually only does
import("./bundle")— the async boundary needed to consume shared modules — and the registrations happen in that chunk. If the main module exports that promise as its default export (export default import("./bundle")), the helper waits for it as well. Remotes without the export keep working as before.see also Patternslib/Patterns#1291