As you may have heard, now that I’m at tCRIL my first big task is to discover what would - and would not - be useful to improve on the micro-frontend (also known as MFEs) front from the community’s perspective. In plain English, we want to avoid spending resources building stuff nobody asked for and few people will actually use.
To cut to the chase:
What are common sticking points with MFEs, currently? And in particular, who does it affect? Feel free to get into dirty details, such as: “one of our customers loses access to [insert feature here], which they use daily”.
How do you think each of those problems could be fixed? Off-the-cuff proposals are fair game: part of the reason for this post is to gather ideas. Plus, I’m sure some of you have at least given thought to some of the issues, already.
How will this help, exactly?
While I can’t guarantee tCRIL will spend resources on every single problem and/or proposed solution that comes up here, we are looking to help address the top pain points, while also pushing the architecture forward to a point where we’re unequivocally better off than we were before - hopefully for a significant majority of Open edX users.
This is just the first stage, though. Once this round of information gathering ends, we’ll use the data to produce a document that will be up for public review. Once that is approved, we’ll go about allocating resources to see it through.
Some additional context
If you look at the discovery ticket, you’ll see it started out being about plugins: but then it became clear that 1) making existing features more usable may be a higher priority, and 2) we don’t know if people actually want plugins - and if they do, how, and what for. (There is, as a matter of fact, a draft of an idea, but at the very least it needs to be developed further.)
I expect that to solve many of the problems, we’ll arrive independently at some form of extensibility requirements. But that’s just a hypothesis: let’s see if it holds up!
@arbrandes From a client developer perspective, the amount of work needed to take advantage of Redux is a huge time-waster and headache. I’ve begun working on a solution for this for a non-MFE based project, but I imagine it would also be useful for MFEs and make client development more accessible. I call this library Providence, and it is built in a way such that it could be retrofitted into existing MFEs relatively easily and put into new ones.
You can check out a demo of this library to get an idea of the expressiveness gains. Getting more teams to try it out will help us make it more generally useful. Right now form handling is scheduled for the next developer sprint, but already it’s incredibly refreshing to work with.
I’m also unsure if these changes ever made it upstream into the frontend template project, but the work I did for the BD-14 translated string handling was massively useful in avoiding entire categories of mistakes with message handling. So I’d recommend making that more available.
I don’t have major issues with MFEs. As we run our own Open edX instance here at EDUlib, I will definitely have some of the same points that everybody else will point out: i18n and branding / theming.
i18n is important for us because we run courses in both fr_CA and en.
Branding / Theming is important to us because we want to have a coherent theme or branding in all parts of the system. We do not want the user to feel like they have left the current Open edX instance to move to a new system that doesn’t have the same look & feel when they end up in an MFE.
We also need to better understand the need of the community. I will take a personal example: the payment MFE.
Had we known in advance that our payment processor (Netbanx / Paysafe) was not going to be supported by the new Payment MFE, I would not have had such a hard time explaining to my management why we could not upgrade to Lilac and then Maple. That was a very bad experience for me. But I’ll be honest, it is not necessarily an MFE issue but more a business issue or a loss of functionality issue. That’s why the community must be involved early in the process and not just when the MFE is ready to be deployed by the Build Test Release Working Group. My 2 cents.
