edX is doing a lot of work to re-implement UI as micro-frontends. This wiki page tracks the work:
https://openedx.atlassian.net/wiki/spaces/FEDX/pages/1920270629/MFE+Rewrite+Status+work-in-progress
One of the things the BTR group needs to consider is how we transition to MFE as the default supported option. Eventually, the old implementations will be removed, unless there is a reason they shouldn’t be. BTR’s opinion will be important.
I have many questions.
Which MFEs are on track to land before our April 9 cut of the release? And which ones are on track to land between April 9 and May 9? I thought maybe I could work this out from the status of each MFEs, but it looks like only two are launched?
Do MFEs work in Tutor?
Can MFEs be deployed to a directory instead of a subdomain?
Can MFEs be themed?
I also have questions about specific MFE implementations, but this seems like the wrong place to ask those questions.
I’ve looked into those aspects in the past couple of months so these are some answers based on what I’ve come across.
@regis did some work to get the grade book MFE to work in Juniper but the same setup requires some changes to work with Koa. This could a place where the BTR group can help as tutor maintainers, personally I’m planning to look into it.
The MFE deployer role has a deployment path using subdirectories but it still requires a subdomain to host all of the MFEs.
OEP-48 Brand Customisation. I have not tested to what extent they can be customised using the brand component.
Also there is a Learner Dashboard MFE that’s not listed on that page, are there potentially other MFE that need to be added?
The “Workin’” category on that page is quite broad, as its definition includes everything from “development just started” to “launched for 99% of edX.org users”.
I don’t have a pulse on every in-progress MFE, but I can say that the following are feature-complete and are rolled out to the majority of our own users:
All of these are under consideration to be default experiences in Lilac, so I am glad that @nedbat brought this topic up.
That is “Course Dashboard”, but no work has development on the conversion yet. I updated the wiki page with that Blended doc.
(edits: course home terminology fixes)
Regarding MFE theming:
MFEs do not implement a mechanism like comprehensive theming, but instead we’re trying to break “theming” down into its component parts and make it easy to do the common cases. To that end, here’s the current state of MFE theming:
Config - Environment variables can be configured at build time, and are responsible for a number of common needs, like site name, URLs to other services, logo location, etc.
Branding - MFEs can be built with a custom brand project forked off of GitHub - edx/brand-openedx. This allows overrides of any SCSS variables defined in the Paragon core stylesheets (along the lines of how Bootstrap generally works).
Headers and footers - In some MFEs, can be customized by forking the frontend-component-header or frontend-component-footer repositories and customizing the contents of the components. Unfortunately not all MFEs use these shared headers/footers as of this writing. So long as the new versions maintain the header/footer component APIs (React props and exports), they can be substituted into an MFE by installing them in the MFE at build time, overriding the dependencies for frontend-component-header and frontend-component-footer. This is what’s done on edx.org today.
Further customization and extension - MFEs do not today allow for component customization or extensions short of forking the repo. That said, we hope to be using webpack module federation to allow plugins, and a webpack alias mechanism to allow custom component overrides, similar to how we allow header/footer overrides today using npm aliases. Between the two, that would allow “supported” customization through a plugin mechanism, and for those that really need something unexpected, “unsupported” customizations via component overrides.
Happy to give more detail on any of that!
Hey @arbrandes ; do you mind if I drop in to this Monday’s meeting to talk MFEs? More specifically, I want to figure out a strategy for enabling community use of MFEs (starting in Lilac if possible!) so that we can start getting rid of some legacy code. If there are gap areas–theming, deployment, etc.–I want to make those clearer and see what we can do about them.
Why, not at all! It’s a great idea, and totally on topic. Please do!
If we go with recommending/enabling three MFEs by default for the upcoming release, is there anyone who is interested in getting path-based routing working for those three MFEs, so we don’t have to deploy them on separate subdomains?
Seems like we should also make sure that the MFEs we’re enabling by default for the release use frontend-component-header and frontend-component-footer.