To overwrite components, users should be able to fill pre-defined locations ("slots") in the user interface with their own content.

[jmakowski1123]

Problem

For overwriting components, currently, one has to rely on either forking or module aliasing to achieve some form of extensibility, but this is clunky at best.

Product/Platform Value

Like runtime configuration, a solution for customization would allow use-cases that are not currently possible with MFEs but are possible with Comprehensive Theming. Feature parity here would greatly improve adoption, as it would allow many providers to actually upgrade to newer releases.

Acceptance Criteria

Related or in-progress work

This is laid out in the Experience Plugins section of David Joy's MFE customization draft OEP then further specified in the MFE Plugins draft OEP.

However, the work on the OEPs themselves has not moved forward and needs a new owner."

Contingencies

[brian-smith-tcril]

I just read through the MFE customization OEP draft, and there are some great ideas in there!

A couple things stood out to me. The first was a large focus on avoiding MFE forks. This makes we question if we just not offering enough tools for customization in paragon components.

This question is reinforced by

Note that component overrides is akin to "comprehensive theming" supported in edx-platform's legacy frontend interfaces. Ideally it shouldn't be used at all, but exists as an "escape hatch" for when all else fails.

This makes me think that we might want to look into the reasons people are using MFE forks, and see if it's possible to provide the missing functionality upstream as a configurable option.

That being said, if having full on components added outside of the webpack build is desired, we need to prove the concept. A next step for that would be to think of some use cases for component overrides, and then build out a couple proof-of-concept implementations.

I'd want to:

• See an example of a component that needs overriding that can't be handled via vendor theming (either using existing theming or by extending our css theming abilities)
• Figure out what an ideal deployment/dev experience for component replacement would look like.
• Figure out what we need to maintain for the component replacements to not break with upstream changes.

[arbrandes]

@brian-smith-tcril

we're just not offering enough tools for customization in paragon components.

We're most definitely not offering enough tools, which is the main motivation behind this issue. Going with slots (or "holes") in the page is one way to improve that. For instance, allowing deployers to fill them via iframes and the corresponding URLs set via environment configuration. The purpose of this particular issue is to investigate this approach.

[arbrandes]

@brian-smith-tcril, also, I suggest taking a peek at my State of the Frontend talk given at the conference in the beginning of the year: it should give some context quickly on many of the things we want to do going forward.

[brian-smith-tcril]

Going with slots (or "holes") in the page is one way to improve that.

I think this would make more sense to me if I had an example. I have a few ideas for how slots could work and be implemented, but I don't have a full understanding of the problem they are trying to solve.

I think that looking at examples from users that have forked MFEs, as well as users that haven't moved over to MFEs due shortcomings in customizability compared to comprehensive theming would go a long way for defining the problem to me.

[arbrandes]

Closing this as a duplicate of openedx/platform-roadmap#27. (We created this one a bit prematurely, I think.)