Replies: 1 comment
-
Use a runtime plugin? |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Case
I'm investigating the solution of a plugin system. It should be like:
User query an api at the frontend, then get the up-to-date list of plugins.
User select one plugin, then it loads the component from remote server to local browser and render it.
With module federation, I can achieve half of it. In this example, the producer has a mapping of exported entry to the actual component, and the consumer can lazily load the one it needs.
Then, I check the producer code, seems the "exposes" field is hard coded into generated
remoteEntry.js
file.Idea
Is it possible to provide a unified toolchain to bundle a package as the one in the "exposes" field, then import the package by providing a dynamic path to the provider?
Let me illustrate the idea with an example:
app2
configures{ './Widget': './src/Widget.tsx' }
as its "exposes", then say the generated bundle file of./src/Widget.tsx
is./dist/abc.js
, soremoteEntry.js
would hardcode a mapping from./Widget
to./dist/abc.js
my-widget
whose./src/index.tsx
is the same as./src/Widget.tsx
above, then a toolchain could bundle the package the same as./dist/abc.js
above. Therefore, I can provide a dynamic mapping from./Widget
tostorage-location/my-widget
to the producer. At any time, I can add new packages tostorage-location
directory and update a list, soremoteEntry.js
can always be up to date.This is a premature idea. Module federation's role here is a manager that deals with shared packages (especially the singleton React). I don't know if there are other alternatives.
Beta Was this translation helpful? Give feedback.
All reactions