-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create a plug-in API to make it easier to modify or improve MFEs without forking #430
Comments
I left a comment related to this on #429 tl;dr - what are people doing with comprehensive theming that we don't support in MFEs? can we support that by making paragon components more customizable? what should the dev/deployment flows for plugins look like? |
"Comprehensive theming" is essentially overriding templates server-side. That allows for overriding basically anything in a page. People would (ab)use this to their heart's content. When moving to micro-frontends, we lost this ability, and will likely never get it back completely. The motivation here is precisely to find out how we can get to a place where 80% of the customization needs (including theming/branding) are covered without requiring users to fork the MFEs. |
This topic was discussed in today's Architecture Coordination Working Group meeting. Looks like we might have/want to move this up. |
Setting aside a few hours this sprint to investigate how we can move this forward, via #521. |
Found this: a specific use case for plugins that I had not seen, yet. |
This is technically the primary roadmap issue behind the upcoming Frontend Pluggability Summit. This is the summit's current wiki page. |
Actually... This is the main roadmap issue: I'm closing this one to avoid confusion. |
Problem
edx-platform already has plugins, and it has made development much better. Some form of extensibility architecture should be created so that MFEs can be modified or improved without the necessity to fork them.
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
Contingencies
The text was updated successfully, but these errors were encountered: