There are significant changes underway to how MFEs work. These changes have already started showing up in MFEs, in tutor-mfe and by Willow they should all be converted to the new way of working. In this post I’ll try to summarise all the key changes without going into explicit detail.
The key theme of these changes is to make MFEs more composable and flexible, reduce the build time and bundle size, and improve navigation speed.
In very very short, the changes take the concept of slots and expand them to a whole new level. Imagine starting with a blank MFE where you have a slot for the header, a slot for the footer and a slot for the main content. Instead of our usual small plugins the slot contains the entire learning MFE. This is what we have with the new frontend-base refactor.
The new frontend-base repo takes over all the responsibilities of frontend-platform, frontend-build, frontend-plugin-framework and the header and footer slots.
The idea is that you start with your own copy of the template at frontend-template-site. This contains files called site.config.dev.tsx and site.config.build.tsx for dev and production respectively. These files can be used to do deep customisations of a client’s site. You can configure which MFEs you want to use, which slots you want to configure and how everything connects. Or you can let tutor-mfe handle it.
Instead of each MFE being a separate app, they are now all built together in the same site with individual dynamically loaded chunks so when you navigate from one MFE to another, it isn’t a hard refresh that loads the same libraries all over again, it only loads a chunk container the new MFE without refreshing the page.
MFEs also expose the routes they provide so there is a lot of flexibility in changing routes around, adding custom pages, and even using an external link in place of a MFE. For instance you could configure a completely external page as the profile page etc.
Since MFEs are essentially themselves plugins that go in a slot you can even have one MFE providing slots to another. For instance, instead of loading the discussion sidebar in an iframe, the discussions MFE can contribute the component that will go in that sidebar and it will render as a native component rather than an iframe.
The way slots work will also change once all these changes land. Some common things we do such as using a Wrap slot will no longer work as-is, because Slots now support a more complex mechanism called layouts. Other features that were a bit hacky or needed a fork such as a custom syllabus tab for courses are now natively supported.
I am working on a developer guide for the new frontend-base versions of MFEs. If there are any particular questions you’d like answered or areas of confusion, do ask them here and I’ll make sure they are covered in the guide I create.