PoC: wait for Module Federation remotes before the initial scan and implement replace option - #1291
Merged
Merged
Conversation
…itial scan Module Federation remote bundles (add-ons) register their patterns and components asynchronously after document ready, while the registry scanned the DOM right at document ready. Whether an add-on's pattern override or component registration was in place for the initial scan was a race between the remote's chunk loading and the host's own initialization — usually won by the remote, but not guaranteed. ``registry.init()`` now awaits ``window.__patternslib_mf_initialized``, the promise provided by the Module Federation helper of @patternslib/dev, before the initial scan. Without a Module Federation host on the page nothing changes. A timeout (default 5000ms, ``window.__patternslib_mf_init_timeout``) makes sure a broken or slow remote cannot block the page; the scan then runs anyway with a warning. Repeated ``init()`` calls while waiting are ignored.
Member
Author
|
see analysis and usecase here plone/mockup#1637 |
… pattern
The first registration of a pattern name wins, so an add-on bundle
could not override a core pattern under its own name — it had to
blacklist the original and register a replacement under a different
name with the original trigger, and then bridge the original's
options by hand.
``registry.register(pattern, name, { replace: true })`` now replaces an
existing registration; ``Base.extend`` accepts ``replace: true`` as
pattern property. Together with the registry waiting for Module
Federation remotes before the initial scan, the replacement is in
place for the initial scan no matter whether the remote or the core
bundle registered first. Replacing after the registry was initialized
logs a warning: already initialized elements keep the previous
pattern, only new elements get the replacement. The blacklist still
wins over a replacement.
Also documents the new Module Federation globals in the README.
replace option
thet
approved these changes
Sep 11, 2026
Member
There was a problem hiding this comment.
Also looks very good to me and solves a registration problem very elegantly.
Up until now, a pattern from an add-on remote bundle called registry.register to register the pattern and re-run a dom scan when the scan was already done. Now - with everything in place (also for the enty point's export default import("./bundle"); trick - undocumented yet, but there is not much documentation anyways), everything is done only once and there is a better way to override existing patterns.
Sounds like a big win for me and a more stable overriding situation.
Approved!
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
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.
Module Federation remote bundles (add-ons) register their patterns and components asynchronously after document ready, while the registry scanned the DOM right at document ready. Whether an add-on's pattern override or component registration was in place for the initial scan was a race between the remote's chunk loading and the host's own initialization — usually won by the remote, but not guaranteed.
registry.init()now awaitswindow.__patternslib_mf_initialized, the promise provided by the Module Federation helper of @patternslib/dev, before the initial scan. Without a Module Federation host on the page nothing changes. A timeout (default 5000ms,window.__patternslib_mf_init_timeout) makes sure a broken or slow remote cannot block the page; the scan then runs anyway with a warning. Repeatedinit()calls while waiting are ignored.