I’ve invited you both.
1 Like
I’ve added @Felipe 's use case to a table in the wiki page.
Please add any additional use cases that you have seen or need to fulfill.
Big thanks to eduNEXT for your teams investment in reviewing the current proposals and sharing your requirements.
Hello Team,
I hope this message finds you all in good health and high spirits.
First and foremost, I want to extend my appreciation for the initiative. It’s a significant step toward advancing the customization capabilities within the MFEs.
Regarding the proposal Extend a POC. I’ve delved a bit into the details of the PR and I have 2 questions about it.
-
Could you explain more about how multiple child Micro Frontends (MFEs) can coexist within a single plugin slot and what considerations are being taken into account to ensure smooth interactions and compatibility between these MFEs?
-
Furthermore, What mechanisms are considered to handle cases where a plugin cannot be rendered? Could you provide information on potential fallback strategies and how they will be determined?
Somewhat… you can wrap it in another component and then use useEffect in your wrapper to trigger something to happen before the component loads, or to make the component loading conditional on something. Running code “after” the component loads would be much trickier unless the component itself accepts an onReady prop that you can use to register for that event. To change what is displayed when loading, you could wrap the code in a custom <React.Suspense> component.
I haven’t tried that yet. Maybe, it’s possible that you could modify the router definitions using slots just like you can modify any other component. If I get time, I’ll try it out and see what happens. But in any case, for something like this as long as Dashboard was defined as a <DefaultUiSlot>, then you could also just wrap the <Dashboard> component and replace it with your own component entirely, without changing the router.
1 Like
Folks, I made a proof of concept showing how the “Pages & Resources” page of the Course Authoring MFE can be re-built using a plugin model. I think this is a perfect real-world use case for plugins, as the backend is already plugin-based but the frontend is hard-coded into the MFE.
For now, this is just using an ad hoc plugin framework that’s fairly specific to this page, but if I get more time, I’ll try to show how it could be refactored to use the UiSlot approach and/or create some more realistic examples of “plugin-ifying” our current MFEs.
Screenshot (each card with a gear symbol on is implemented by a plugin, other than “Discussions”):
4 Likes
Was not in the WG calendar, but I’ve added it
2 Likes
Hi Ed,
Working with MFE’s in the past, I faced similar challenges but I tried to make it work by using the environment configuration approach. That’s why I think this summit is very crucial for distinct user functionality.
There are two important points in the requirements above and those are, the solutions should be:
1- Backward compatible meaning it should enable easy upgrades
2- It should not alter the shared foundation
The solution suggested by @Glib_Glugovskiy is closer to the above requirements. However, I feel if we implement a solution that lives in total isolation then it might not be easily backward compatible.
I think the plugins should be allowed to leave a very small footprint on the base repo’s, could be just a comment to the overriding functionality as provided by the ScandiPWA plugins to magento themes.
This will help override the parts of the existing functionality, instead of the full file override and enable easy upgrades.
I think the solution could be a monorepo where it can install / contain different MFE’s and provide the plugin solution which can be injected at build time by following the little footprint added to the base repos. E.g.
To the base MFE function we added the below comment to create a build-time proxy for the getData function.
/** @namespace my-host-app/getData */
const getData = () => [1,2,3,4];
And our plugin could provide a totally different implementation for this getData which could replace the source at build time.
export default {
"my-host-app/getData": {
function: () => [10,20,30,40,50]
}
}
Hi all,
Just wanted to request and make sure this meeting will be recorded. Unfortunately the announcement of this summit and the date picking happened while I was on leave, but I am keen to at least keep abreast of what happens. 
1 Like
Hello everyone, I’ve created a draft agenda for tomorrow’s meeting.
Please chime in if you would like to add anything. I have signed a few folks up to give demos of the candidate solutions that have been proposed. So, @braden @Jason_Wesson @Glib_Glugovskiy @arbrandes please note that I’ve reserved 15 minutes for each of you to discuss your proposal, walk us through some details and field questions.
1 Like
Apologies for being wholly absent from the discussions - my job these days has me far afield from the Open edX frontend, sadly. I love that this is happening, am excited to listen in, and will be there tomorrow. 
1 Like
Hi all! I’ll be attending to represent MIT OL Devops.
1 Like
Hi! I will also attend from the MIT OL Engineering team.
1 Like
Hi all, This is a great initiative. I also have a tentative plan to join from MIT OL Engineering team.
Thanks everyone for attending the meeting today.
Here’s the link for the recording, Video Conferencing, Web Conferencing, Webinars, Screen Sharing - Zoom
3 Likes
For the record, there was a follow-up conversation about pluggability during the last Frontend Working Group meeting. The details are in the notes, but the important decision that was taken is the following:
Instead of waiting for a full set of pluggability OEP and ADRs, and as per the action item at the end of the summit itself (“suggest new proposals that address most use cases presented”), we’re going to allow individual MFEs to implement different, repo-specific plugin architectures. This will let us iterate on the real use cases, with the intent to converge on a global architecture faster. How fast? Before Redwood fast.
@Jason_Wesson and I have already started discussing the details of doing just that to Learner Dashboard. In short, Jason’s team will implement an iteration of his Iframes proposal that already brings it closer to @braden’s “UI Slots” write-up. We’re not sure how close, yet, but rest assured that:
- There will be an accompanying ADR in the PR where we’ll ask folks to chime in for a short review; we’ll let y’all know in this thread
- Even if the first iteration is not satisfying for everybody, further ones should strive to address all relevant comments
- We aim to converge at an architecture that does work for that magical 80% of use cases before the Redwood cutoff
At the same time, we expect to entertain similar changes to other MFEs as long as the maintainers are on board with the experiment. For instance, I encourage the same people that intend to review the changes to Learner Dashboard to review Braden’s PR to frontend-app-course-authoring seriously, and for Braden himself to pursue merging it. Hopefully, the ensuing cross-pollination will help both initiatives converge.
3 Likes
Sure, I’m happy to finish up and merge that PR.
1 Like