feat(runtime): provide a root #3740
Conversation
|
✅ Deploy Preview for module-federation-docs ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
| </ul> | ||
| <Routes> | ||
| <Route path="/" element={<Root />} /> | ||
| <Route path="/remote1" element={<Remote1 />} /> | ||
| <Route path="/remote2" element={<Remote2 />} /> | ||
| <Route path="/remote3" element={<Remote3 />} /> |
There was a problem hiding this comment.
Behavior is odd... Loading the page directly attaches the CSS correctly, navigating to it through a link doesn't because css assets is missing in the manifest... It's almost like the built code caches something different than the hardened runtime which uses mf-manifest.json?
| @@ -70,6 +70,7 @@ export function preloadAssets( | |||
| assets: PreloadAssets, | |||
| // It is used to distinguish preload from load remote parallel loading | |||
| useLinkPreload = true, | |||
| root: HTMLElement = document.head, | |||
There was a problem hiding this comment.
A fatal flaw with the current approach is that when you load something (or preload something) it gets cached by id in a global. Subsequent calls to retrieve assets no longer returns those assets. So ultimately, Federation only supports a single root per global. 😞 To fix this I think we'd need to make sure that this code:
Somehow respects caches on whether it's been loaded for a specific root. Not assuming a global loading approach.
|
Nice PR ! But I have a small question: Will you only use loadRemote api ? Will you use I ask this is because if you use |
|
And can you help add the new feature doc ? |
Description
Allows providing a root element to loadRemote so that it can be used with shadow dom. If one isn't provided it falls back to current
document.headbehavior.Related Issue
#3746
Types of changes
Checklist
Would love guidance on how best to test and implement this, if this is even the right API idea.