Module Federation Q&A

Steve Kinney

Steve Kinney


Check out a free preview of the full Vite course

The "Module Federation Q&A" Lesson is part of the full, Vite course featured in this preview video. Here's what you'd learn in this lesson:

Steve explores the use of module federation, discussing the possibility of assigning a function to the exposed object and experimenting with programmatic manipulation. Practical demonstrations and addressing TypeScript-related issues are also covered in this segment.


Transcript from the "Module Federation Q&A" Lesson

>> Is it possible to give the exposes object a function instead of an object?
>> No, these are file paths, right? In terms of like, yeah, can we do it programmatically? Let's find out together. It looks like it's just a string, and array. You can get an array of those objects or an object, it seems to be the only two options in the type.

But great question. Cool, so here we'll do, we have the NPM run build, so we'll just do a npx vite preview. And then just verifying that I made that the correct. Show many, we want that to be React one. Verify, yeah. Okay, let's find out together. We got some TypeScript angriness, but we can deal with that.

Again, we could generate a DTS file and still pull that in as a library too. It will be slightly off if it changes, but that's what makes this all hard. So npm run dev. Let's find out. Open in my other Window, but there it is. There's our button hosted remotely, right?

So theoretically let's try this out let's go ahead and on our remote one we're gonna go let's change some of the semantics of the button let's say that the button color is, background color is Cool, and we'll do a npm run build. It is angry about that, oop, no, it was there.

>> Contained in there still, get the hex for the color.
>> See, this is why you don't trust other people shipping you code, even if it's you, cuz they make mistake and who's getting paged now? Other me from the mistake that this me made. If I didn't, we got to build again, see?

Now all of a sudden your page is going off, right? I'm already in trouble for the last time I like was talking to a microfinance. This is not gonna go well for me. The Internet is not gonna be happy with me when Mark makes this a TikTok video.

There it is and now it's purple, right? And so you can remotely change code in one place. Everyone consuming this gets it hoping that nobody on the beginning end. And accidentally puts a hashtag before Rebecca Purple, and you should be good to go. Like I said, there are useful places.

If I was going to use this, and I do use it, I would do it with an abundance of caution, with fallbacks all over the place, right? And so I would most likely replace the nav bar, that maybe, I would basically do both. I would have the library, right?

And then have this function replace the last version so that if we pushed out a new version, cool, they get the new one, but if it breaks, it'd just fall back to a slightly older nav bar or something along those lines. I think that there's a lot of power in this, but with an abundance of caution as a thing that would keep me up at night.

>> What if the hosted app is React and the expose library is built in VIEW?
>> Good luck, [LAUGH] I mean, theoretically, if you think about it cuz I mean, yeah, you would need to be able to like do something with what you receive. Now, there are ways to handle that, right?

Theoretically, I'm just exposing the component. What I could do is expose a function that takes an ID or selector and then does react dom.melt and these days into that div, right? So for instance the navbar is spelt but I'm gonna render it into React application. So I can use felted TSX that's the thing, or I can just say, yo instead of exposing the component I suppose a function that takes a selector and will render it in there, all right?

You can do that you can mix and match frameworks as much as you want, right? You could have view render into one div on the page. A lot of times we do when we use any frameworks we just have like an empty div and our single page app that is like root or app or something like that, but you could just render React just into a sidebar or just into a menu bar.

Those are all work, but you couldn't just consumer React component and view without some like tom foolery, right? And I say it's impossible, I'm just saying it's not a built in thing, right? Same way if you took a React library that wasn't module federation, and you tried to use a new view app, could you do it?

Sure. Are you in for a rough time? Absolutely, right? But yeah, at that point, I would just target a DOM node and call it a day.
>> Is there a simpler approach to module federation or approach that you would use that is?
>> Yeah, I would just make a library.

Right, I think discussing that you can do module federation is important. I, especially as the manager of the team and the one who runs front end at the company, I am by default, more conservative than the average developer, right? In terms of like the risks that I'm willing to take and so, I do with an abundance of caution, what we do, we'll do it on like low risk situations where again, updating for websites with a new navbar or a new button or whatever, it's tedious, right?

In our core app I told you we have that open source one and then we actually package up the open source app because the cloud app is a superset around it. We do that manually. We bump the version. We check it in staging, and we deploy it, right?

We opted out of the convenience for the safety. However, I know people who work at a very, very big corporation with a hundred front-end teams, and just based on the nature of their architecture, that's not feasible and this is the way forward for them. I have personally made the decisions in my architecture not to need, to do this so much, again, I will do it for if the navbar on the docs page falls back to the one built into ducky Soros, everyone's gonna live.

You know what I mean? If the navbar on the education site doesn't render at all for an afternoon, that's not great, but if it takes down the product that makes us money, I'm in trouble, [LAUGH] right? So it is there as a tool. And I do know, one of the reasons we included it was that when I talked to a bunch of senior engineers at a company that I probably I can't name, but whatever, they're we need this cuz, that is the way our architecture is set up.

So, it is an option. And there was a belief system that only Webpack had this, right? Vite clearly has it. On the very basics, not particularly hard to set up. That doesn't mean that I endorse it, [LAUGH] per se, or think that it's a good idea. Let me rephrase that.

I actively think it's not a good idea. But there are practical use cases, but I would treat it with an abundance of caution. I say that, be like, Steve showed us this thing and it looks super cool, we should do it everywhere. Stephen Lee is not endorse this message.

My job is to inform and it was definitely the first thing every senior engineer said to me when I was running this material past them. So I felt like for the people who need it you know already, like you've probably built more infrastructure around it than I have, right?

Because I've actively chosen not to, right? When I worked at Twilio, we did move everything back into a mono repo on purpose for reasons like this. Now, granted, the tooling when we made that choice was not as good as the tooling is now. We had 17 versions of react in a 10 year old code base mixed with backbone and Marionette and 1,000 other things.

So a modern code base might be better set up and resilient, but we made the decision to kind of co-locate everything so you could run one integrated test suite at a one repo in one build process. I've usually gone the mono-repo route and not regretted it, but I do know that the micro-funding route is also popular, it's just not the one that I endorse.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now