Question about docs, bi-directional communication for dynamic imports

[kahboom]

I'm trying to share state between two React apps (one host, one remote), where the remote shares a button, and the host has a set of functions that can be triggered by clicking the button in the remote. I'm using dynamic loading. But when I click a button from the remote, I get props.<custom function> is not defined followed by some CORS error (Uncaught Error: A cross-origin error was thrown. React doesn't have access to the actual error object in development., which I wasn't sure if it was a red herring). The initial loading of the remote container works as expected (i.e. I'm able to see the button). All of this is done locally, if it matters.

Anywho, in the docs, it states the following:

Uncaught TypeError: fn is not a function
You are likely missing the remote container, make sure it's added. If you have the container loaded for the remote you are trying to consume, but still see this error, add the host container's remote container file to the HTML as well.

I may just be stupid, but it's not entirely clear to me this part: the host container's remote container file to the HTML as well. Am I supposed to add the expected path of the remoteEntry.js to the remote's public/index.html head? Or define it somewhere in the webpack.config.js file, like HtmlWebpackPlugin? Any examples would really help. Thanks!

Bonus question: Would something like this enable me to provide typings for my host's functions? Or is that not a thing?

This is my host: https://github.com/KaotoIO/kaoto-ui/blob/main/webpack.common.js#L88 Dynamic import script: https://github.com/KaotoIO/kaoto-ui/blob/main/src/components/import.ts Lazy loading happens here: https://github.com/KaotoIO/kaoto-ui/blob/main/src/components/StepViews.tsx#L178

Here is my remote: https://github.com/kahboom/cosmosdb-source/blob/main/webpack.config.js

[ScriptedAlchemy]

Don’t use bundle loader. I’d start with removing that. Fn is not a function, usually caused by either a chunk loading from the wrong origin. Like public path isn’t set to auto. Or if you are using dynamic remotes. Ensure the factory actually returns exports you’d expect

[ScriptedAlchemy]

Might be related https://github.com/module-federation/module-federation-examples/issues/2066

[kahboom]

Thanks @ScriptedAlchemy . Didn't get a chance to work on this again until yesterday. Ran into some issues that I was able to resolve, in case it helps anyone:

• Uncaught TypeError: Cannot read properties of undefined (reading 'init') → Forgot to match the names of the exposed module and where I was importing them (again 😂)
• Invalid hook call. ➠ Didn't properly align dependency versions for React in the remote, eslint was upset
• host_blahBlahApi__WEBPACK_IMPORTED_MODULE_1___default(...) is not a function ➪ erhmm I think this one was resolved with your help Zack, publicPath wasn't set to auto
• Cannot read properties of undefined (reading 'displayName'). Warning: lazy: Expected the result of a dynamic import() call. Instead received: [object Module] ↳ Forgot to add an export default <ComponentName> at the bottom of the exposed component page.
• Removed bundle loader

Didn't end up needing optimization: { splitChunks: false }. For the typings, I am generating types using webpack-remote-types-plugin and consuming them with TarWebpackPlugin for now.

Main thing missing now is to see if this could be helpful for retrieving the types at runtime from a dynamic host, since we won't always know the hostname, and want to avoid multiple remote deployments that depend on environment variables: https://github.com/module-federation/enhanced

Anyway, the project I linked to is open source, very much alpha but anyone can use it if it helps them to see how we're using module federation, at least in a small greenfield project that will hopefully be used in a big hybrid cloud environment down the line (awesome work btw Zack 🤘). We're using module federation at scale at Red Hat for many of our cloud services.

[kahboom]

also, unrelated, but I probably shouldn't have worded this issue as "sharing state", it was more about getting dynamic import working when the host is also sharing methods with the remote, so bi-directional communication.

[ScriptedAlchemy]

Hey check privjs. We have a free module federation TS integration. Would love more feedback on it

I'm glad you got it working. Enhanced will get more attention soon. I'm going to be basing a lot of my ecosystems ontop of a better api.

We are getting very close to launching http://Medusa.codes - which would give give you a dashboard to command and control federation on demand for various environments. One thing high on the list is pair it with a chrome extension so that you can switch remotes on your browser in any environment you want, without impacting that environment.

I believe the main thing to nail is some way to harness more power given the ease of doing so.

The version management that I'm testing at the moment uses the git commit Sha as its version. So the remote name and entry is hashed - multiple versions of the module can exist on the page at once without collisions (nested remotes) Idea being I can pick any commit hash I've pushed to GitHub and use it anywhere else without needing to redeploy.

[kahboom]

@ScriptedAlchemy awesome, checking out Medusa now. thanks!

[ScriptedAlchemy]

Also module-federation/typescript now on npm and GitHub