@guruprasad - This is a brain-dump of the roadmap for theming in MFEs as I see it, several parts of which are in progress/planned already. OpenCraft has been instrumental in pushing all this forward! This is not a complete answer and clearly needs to be codified into tasks/epics a bit more.
Traditionally, theming has meant a whole combination of things in Open edX. It has meant custom logos and site names, branding and stylesheets, configuration, plugins, and component overrides. In various situations it’s also verged on conversations about custom CMS for marketing sites.
I think our approach to theming needs to be more nuanced and granular, to the point where I hesitate to use the word. There should be well-supported, documented mechanisms for doing ~90% of what people generally need to do when making a custom theme, and then “power user”, lower-level mechanisms for doing that other ~10% of deep customization.
To break this down:
- Configuration
There are many things that should simply be configurable and well-documented. These can be changed merely by updating a configuration file at build, or potentially even runtime. Site name is a good example, but so are URLs, cookie names, feature toggles, etc. This mechanism already exists, though it lacks consistent documentation.
- Branding
edX’s internal rebranding efforts are pushing forward a notion of how we can do branding in MFEs in an easy way that doesn’t involve forking the repo or Paragon. This includes colors, fonts, padding, etc. This is what @abutterworth’s proposal in Nimisha’s comment above is addressing, and it allows for stylesheet and asset customization.
- Plugins
We’re working on a full-featured, LTI-based plugin mechanism, sandboxed in iframes, and a lighter-weight “privileged” plugin mechanism (running in-page) for extending MFE applications in pre-defined “slots”. The first step to this was to free our LTI implementation from the LTI XBlock, which is well underway (as Giovanni knows well!). Subsequent steps will be the creation of client-side libraries and configuration mechanisms to let developers write plugins, add plugin slots to existing applications, and to allow for runtime configuration of an application’s plugins (hopefully by non-developers)
- Component Overrides
This mechanism would allow developers to substitute their own components into the application at build-time. We already have a similar feature in @edx/frontend-build which allows local development of dependent packages (like Paragon) in an MFE, so you can see updates to a shared component, header, or other library in real time as you work on it, in the context where you’re hoping to use it.
We can add some configuration to the MFEs that allow developers to specify replacement components for anything in the app. As you’d expect, this would be pretty powerful, and allows you to modify application behavior at any level without needing to fork the whole repo.
With great power, though, comes great responsibility. This is most akin, I think, to “comprehensive theming” as it exists today, and should be used as a last resort. The code in the app will evolve, as these things always do, and there’s no guarantee that the internal interfaces in the app will not shift around.
- Componentization of MFEs
This is a pie-in-the-sky improvement to component overrides, where we are able to componentize chunks of the app into re-usable, composable elements. You could envision making a new MFE that installs a versioned release of “@edx/frontend-app-profile” as a dependency and then uses its public exports - parts of the profile MFE - in some new application. Or install frontend-app-learning and drop in a Learning Sequence somewhere.
So there’s a lot there. The goal here is to find simple, maintainable, document-able mechanisms for accomplishing most of what the community needs to do under the auspices of “theming” today, and then increasingly technical escape valves for true customization and hacking. Put another way, someone wants to do some branding or add a feature to the UI, we want to avoid a situation where they’re tempted to use a “comprehensive theming”-style mechanism to do it. That’s shooting a fly with a cannon.
While we wait for