Preparing for upcoming switch to MFEs

Discussions - Public
1

Hello @team

As you may be aware, the Open edX project is steadily moving toward MFEs, to the point where now with each release, new MFEs are being enabled by default and legacy experiences are starting to be deprecated and removed.

The Learning MFE was enabled by default starting with the Maple Release and now the Account MFE has been enabled by default starting with the Nutmeg Release.

During the Maple upgrade, we had decided to continue using the legacy learning experience using appropriate waffle flags as MFEs were not yet fully themeable. We plan to continue doing the same during the Nutmeg upgrade for both the learning experience and the account pages.

However, with Olive Release both the legacy learning experience and the legacy account pages are slated to be removed. The legacy learning outline tab has already been dropped from the master branch.

The current state of themeability of MFEs are as follows:

  1. Branding:
    MFEs currently fully support brand customizations, i.e. relevant SCSS based colors can be overridden and custom logos and favicons can be included. This can be done through a branding package.
    Branding package is fully implemented in our edx-simple-theme and is ready to be used to customize MFEs.

  2. Custom headers/footers:
    Currently MFEs do seem to support customized headers and footers using frontend-component-header and frontend-component-footer packages respectively. We should however do a discovery to figure out how to use these packages and develop sample overrides.

  3. Custom templates:
    With comprehensive theming, we had the ability to heavily customize html templates in the legacy experience. However, MFEs currently do not have any easy way to do such template customizations. The only way to implement such customizations right now is to fork each MFE and modify the contents therein. Maintaining such custom forks for a growing number of MFEs for each of our clients would be impractical.

As you can see, this could have a huge impact on almost all of our clients, since all of them use custom themes with varying amounts of customizations and starting Olive, we would not be able to avoid MFEs anymore.

Therefore, we need to start preparing right now, so that we are ready by the time we start doing the Olive upgrades. This post is intended to kickstart this process.

As discussed during the last Bebop Sprint Retrospective, these are some of potential steps we could start taking now to prepare for this shift:

  1. Develop ways to easily customize templates of MFEs perhaps through NPM packages, similar to what was possible through comprehensive theming. This would be a complex project, but one which would benefit the entire community. Perhaps, we could explore if tCRIL, edx/2U or some of our clients would be willing to support such an endeavor.

  2. Start porting parts of our client’s custom themes to edx-simple-theme. Currently edx-simple-theme can be used to customize almost all colors, logos, etc. for both MFEs and legacy experiences and is fully supported by Grove. So, this effort would mostly involve figuring out the appropriate override values for the different SASS variables.

  3. Start developing header/footer override npm packages, for clients who use customized headers/footers using frontend-component-header and frontend-component-footer.

  4. Start conversations with clients, to discuss with them how they would be impacted by the upcoming changes and the next steps to be taken.

Looking forward to your views on this.

Also, I created this post as private since we could be discussing client specifics here. I could make it public if there are no objections.

Ticket to log time

7 Likes
2

Thanks for this, @kaustav !

I guess that I naively assumed that a lot of our client’s themes would be covered by branding + custom headers/footers. Could you please list some examples of things that our clients are currently using that wouldn’t be possible to do as an MFE theme?

These should be fairly straightforward, right?

MFEs don’t use “templates” as far as I know, so I’m not sure exactly what you’re suggesting here. Could you please clarify? Do you just mean customizing the UI?

If you just mean customizing the UI by adding custom components, I think this is already a largely solved problem elsewhere. Just not yet in Open edX.

For example, Docusaurus recently announced their v2 including a new React theming system (and overhauled plugin system). Their UI is entirely React-based, and their theming implementation is called “swizzling”. From what I hear, it’s excellent. We could just copy that for MFEs. And we could copy what they’re doing for plugins to allow frontend plugins.

(I also implemented React multi-tenant frontend plugins and real-time theming on my other TechNotes/Neolace project earlier this year - see Mattermost. I’m planning to write up a blog post soon about it. It was fairly straightforward and so far has been working well.)

So my suggestion would be:

  1. Make a list of all features our clients have that can’t be covered by simple branding/header/footer overrides.
  2. Try to see if any of those features are not actually necessary, and plan to just remove them if so.
  3. If any other frontend customizations are definitely needed by our clients, implement them as MFE plugins and contribute an MFE plugin system to Open edX’s frontend-platform, heavily borrowing from an existing implementation, like the work already done by Docusaurus. No need to re-invent the wheel.
3

We used client branding and a custom frontend header with the custom course search MFE we developed for Cloudera, and were able to apply those in Koa with ansible MFE: npm_overrides.

My gut feeling is that most clients would be happy with a header/footer that keeps MFEs consistent with their simple theme branding – maybe we could develop these once, and configure them similarly to the simple theme?

Agreed – I think it’s worth revisiting the customizations applied for various clients to find out if they’re still necessary, and if they can be upstreamed to the new MFEs.

Coool… :sunglasses:

4

@braden @jill Sorry for the very late reply.

Here are some examples of customization in some of the client themes I have worked with previously:

  1. Names of existing buttons and fields changed to custom text:
    Ex. “Register” → “Create an Account” or “Forget password” → “Need help logging in ?”

  2. Additonal action button in CMS course outline with custom functionality

  3. Custom redirection behaviour. Such as, redirect unauthenticated user to registration page instead of login page

  4. Custom navbar in the course outline page in lms

  5. Extra js based checks for proctored exams

  6. Custom extended fields in the user account page

Perhaps respective client owners could add more such examples.

Yes, this should not be complicated.
But it would still require some amount of effort to rebuild the custom header/footers in React, especially for clients with heavy customizations such as UQ. Also, these would have to go through QA and approval cycle from the clients, budget for which would also need to be approved by them.

Sorry. I meant customizing the UI to achive results similar to customizing template now, by adding custom components and being able to override/modify existing components.

Wow. Thank you for this. These seem to solve exactly what we are trying to achieve here.

AFAIK, we have an active epic BB-6270 for exploring and implementing MFE based theme customizations. Perhaps @kshitij could clarify if that is the case, and if these resources could be utilized to accelerate the work there.

I completely agree. Should we perhaps create an epic for this and target to complete the excercise before we migrate to Olive ?

5

Glad to see we are planning ahead on this :slight_smile: Thank you!

Btw, any objection to make this thread public? I see some links to examples on the theming repos, but nothing confidential no?

1 Like
6

@antoviaque I definitely think, this dicussion should be made public.

The links in the examples are to private repos of our clients. Will it be alright to have these links in a public thread ? Just wanted to double check this, since I am not too sure.

I could even remove the links before making this thread public, if so required.

1 Like
7

@kaustav Sounds good, thanks! I’ve made the switch then :+1:

As for the links to the private repos, since access is already controlled on the repos, the URLs are harmless imho - it’s fine to leave them.

1 Like
8

I’ve had a look at their system, and it seems pretty neat! Here is my understanding of how it works:

  • You eject or wrap a component you want to modify. Ejecting creates a copy of the component, which you app can load instead of the original, allowing you to significantly change its behaviour. For instance, you could eject a list component and implement it as a carousel instead.
  • Wrapping, creates a wrapper component which loads the original component. This way you can add stuff to the original component. For instance, you could wrap the unit component, and add to it a review tool.

The way it seems to be implemented is, that when you eject or wrap, it creates a copy in a directory that has higher priority for loading the component than the original.

For at-least higher privilege components, this seems like a good mechanism, and it is somewhat similar to the local overrides mechanism I mentioned in the content theming section of my discovery here. There is a mechanism to override individual components built into frontend-platform, which is currently for development only. It can be made into a more supported mechanism.

I think for stuff like this, generally we can just modify the translations for English to do string replacements.

The CMS is currently not an MFE, so traditional methods will continue working.

I imagine this could be implemented using the new events and filters mechanism in the backend. The redirect signal can be given by backend API.

This will need some new plugin mechanism.

I think we should be able to do this with the course-wide extra css and js? Not sure why this can’t be upstreamed, but make configurable.

Yes, content theming is a goal, but currently with the limited budget it is far away. If clients approve some budget, then it can be prioritised accordingly. Right now we’re working towards branding, styling and dynamic theming.

2 Likes