arbrandes
commented
1 year ago Unassigning myself until such time I or somebody else gets back to this.
Open e0d opened 2 years ago
arbrandes
commented
1 year ago Unassigning myself until such time I or somebody else gets back to this.
davidjoy
commented
1 year ago It’s worth thinking about whether the modular MFEs work could help with this, or present an alternate approach, etc. I have that prototype of iframe based experience plugins (PR is linked above), for what it’s worth.
This is starting to come up again for 2U and I’m interested in making some progress here, but I also want to make sure it stays aligned with our other efforts!
arbrandes
commented
1 year ago @davidjoy, part of the hang-up here - at least as far as I'm concerned - is finding an actual use case for a plugin. I'd prefer solving a single case than trying to foresee them.
Things like: Why does the feature need to be a plugin rather than built-in? In which MFE (or library, or component) would it go? Or, as you point out, could it realistically be used across MFEs in a modular architecture? How could it realistically be replaced with something else?
As it happens, I came across an old idea again this week, which is the recurring desire by operators to add custom tabs to the learner view in the LMS. It felt to me like a good starting point for a plugin discussion, but I'm sure you'll have other specific ideas as well. Should we get together to talk about it? I'm sure more people are interested, so maybe we can kick something off in the next FWG meeting.
arbrandes
commented
1 year ago Oh, and something else that has been coming up frequently, which I'm sure you're aware of, is the general desire to avoid having features in MFEs that only work (realistically speaking) for one org. I can think of a few instances of this that happened recently in the Authn MFE, but I'm sure we can think of others, future or present, that might also apply.
arbrandes
commented
1 year ago For future reference, this was such an instance: https://github.com/openedx/frontend-app-authn/pull/758#discussion_r1119155651
Gut feeling says a plugin for this particular use case might be overkill, specially since we already have dynamic config. But MAYBE having a plugin system for dynamic config itself, where different methods of obtaining said config can be used?
arbrandes
commented
1 year ago Just ran into another plugin case, to add to our salad:
https://github.com/openedx/modular-learning/issues/6#issuecomment-1340087025
davidjoy
commented
1 year ago Slots that enable various use cases:
The idea is these are all enable extension points (slots?) that help operators/developers avoid forking and overrides. We don't know exactly what they'll use them for because we haven't thought of it yet, but they're all relatively obviously useful enough that we can imagine them being helpful. In practice, you don't add a slot until you have a concrete use case from someone.
Some of these I can see 2U using to disentangle some of edX's historical choices and simplify MFE code, removing things that were added "for one org" (edx.org). For example, we have enterprise code in the header user menu, we have 'experiments' littering the frontend-app-learning MFE for upsells, cross-sells, and marketing messages, we're likely to have the same on learner dashboard. Frontend plugins would be an obvious way to add custom course tabs in a modern way, rather than reloading the page back to the monolith.
This effort has come up for me recently because I see the 2U marketplace teams eyeing the LMS as a place where they can do cross-sells and upsells, and there's no good way to do this today without polluting the MFE code.
davidjoy
commented
1 year ago MFE Plugins also enable extending the Open edX architecture, especially around ecommerce, catalog, marketing, etc., by allowing configuration of links/functionality that shuttles the user off to parts of the site that aren't in the 'core', so to speak.
arbrandes
commented
1 year ago All of this sounds great to me. Looking forward to helping develop this further!
arbrandes
commented
11 months ago I elect to use this issue to track developments stemming out of the upcoming Frontend Pluggability Summit.
This is the summit's current wiki page: https://openedx.atlassian.net/l/cp/sdRpN2Tw.
Abstract
The ability to extend the user interface of the Open edX Platform is a prerequisite for scalable innovation, customization, and experimentation. It allows us to maintain a small, stable, and extensible platform core, and is a vital part of our micro-frontend customization capabilities.
Micro-frontend plugins (a.k.a., "Experience Plugins" or "XPs") give us a dramatic increase in flexibility in how we build and deploy our user experiences. They enable an increase in team autonomy for feature development, modularization of cross-cutting features, code reuse, and approachable experimentation and extensibility.
Approach and Status
MFE plugins may be implemented with variety of technologies, such as LTI, plain iframes or federated modules. The initial implementation has focused on iframe-based plugins, as they're simpler than LTI, but more secure than module federation, and feel like a "sweet spot" that's most applicable to the community's needs.
We intend to write an OEP on Micro-frontend Plugins describing the above approaches and their relative strengths and weaknesses in more detail. @davidjoy is writing an initial draft (https://github.com/openedx/open-edx-proposals/pull/259, https://github.com/openedx/open-edx-proposals/pull/287)
An initial implementation of iframe-based plugins is currently sitting in a pull request in frontend-platform: https://github.com/edx/frontend-platform/pull/235
Note that this capability depends on improved micro-frontend configuration capabilities. Our current environment variable-based approach is insufficient for build-time MFE configuration. See related tasks below.
Related issues:
Related Repositories
Related PRs
OEPs
Implementations