Proposal of adding a new example

[ahoward2]

Hey everyone!

Based on the work done recently to the FederatedTypesPlugin - I was excited and wanted to put together a comprehensive example and accompanying blog post using it.

The premise is using Zod to validate event payloads to get type safety between host and remotes. This wasn't possible until recently! The apps are configured to run locally and also pointing to the remote hosted on the unpkg cdn.

Wanted to get any community feedback/suggestions on the rough drafts.

• Blog post first rough draft
• Example application rough draft

Notes:

• The remote app has storybook to do local development but for adding to the module-federation-examples repo it may be worth removing it since storybook is quite a large dependency and it's also not everyone's cup of tea.
• css-in-js with styled-components is used. Also not everyone's cup of tea.
• As these are in rough draft stage I'm cleaning up images in the blog post, grammar, may delete / add some sections etc. Same goes for the example app.

Once this is in a good state and there aren't any major pushbacks I'll open a PR to the module-federation-examples, reference it in the blogpost and add a back-link to the post in the example once the blogpost is live.

Thanks!

[ScriptedAlchemy]

storybook can stay, a full example would be nice!
We just dont add it to the monorepo workspace so yarn install will not cover your example, user will have to run install on that workspace independently. I do this for a few examples that have issues with dependency hoisting .

[ahoward2]

Could probably expand this a bit to include the classic e-comm pieces, host-app (app-shell) we already have, header with nav and footer, home page (maybe?), product list page, pdp, and checkout page may cover a full example here. A recommendations carousel is also a common shareable piece on product list pages and pdp. Hold tight, give me a couple days on this. Also went ahead and published the first iteration post. What I'll do is expand the application on the above points and either update the post, or have a follow up post part 2 in the series with the full fledged example.

[brunos3d]

Awesome job @ahoward2! I immensely liked your article and how you approached everything explaining even the terminology, one concern I have looking at your package (@rocket-science/event-client) is the fact that it could break on the server side because of the use of the window object, I assume you consider the app will run only on client-side.

I already worked with events on the window object using pub/sub and event-driven data layer at that time I used my modified version of windowed-observable the global-observable which uses the globalThis object, I know that depending on how your server works it could cause memory leaks, but was the solution I find to make it work in Next.js.

In general, events are an excellent way to share/communicate state changes between isolated federated containers, and EDDL is a powerful way to abstract and moves these events to a proper layer of our MF application.

Google has a good package that abstracts the EDDL and gives some powerful functions to it very https://github.com/google/data-layer-helper

Finally, I would love to hear from you if you already used your set of tools with React SSR or with Next.js 🙂

[ahoward2]

Thanks @brunos3d, that's correct the assumption here is client-side only - a limitation of the EventsClient I put together. globalThis and EDDL are great suggestions, may solve usage on client and server in this case. I'm gonna fiddle around with an SSR case this weekend for it. The core idea is that the event client manages pushing the events to the right location, the user only being concerned with providing the type interfaces for Listeners and Emitters, providing event payload schemas, and handling the listeners. Until I can get this working with SSR, will be updating the considerations section in the post with the "client-side only assumption" here. Greatly appreciate this feedback and the suggestions. 🤩

[ahoward2]

Awesome job @ahoward2! I immensely liked your article and how you approached everything explaining even the terminology, one concern I have looking at your package (@rocket-science/event-client) is the fact that it could break on the server side because of the use of the window object, I assume you consider the app will run only on client-side.

I already worked with events on the window object using pub/sub and event-driven data layer at that time I used my modified version of windowed-observable the global-observable which uses the globalThis object, I know that depending on how your server works it could cause memory leaks, but was the solution I find to make it work in Next.js.

In general, events are an excellent way to share/communicate state changes between isolated federated containers, and EDDL is a powerful way to abstract and moves these events to a proper layer of our MF application.

Google has a good package that abstracts the EDDL and gives some powerful functions to it very https://github.com/google/data-layer-helper

Finally, I would love to hear from you if you already used your set of tools with React SSR or with Next.js 🙂

Typically you would add event listeners in useEffects which is fine if you're using SSR since they don't run on the server. In what cases might this be insufficient or in what cases would you want components to emit / add event listeners on the server?

RSC may be a different story though.