XBlocks in MFEs: Brainstorming Session

Date

Nov 30, 2023

Participants

@Adolfo Brandes
@Feanil Patel
@Braden MacDonald
@Dave Ormsbee (Axim)
@Sarina Canelake
@Jeremy Ristau
@Brian Smith
@Kyle McCormick
@Edward Zarecor

Recording

Notes

How can we render XBlocks "sanely" in MFEs? Cases in point:

How can we support React-based blocks that work well in Studio, in preview mode, and in the LMS, without having to treat each environment as an exception?
- Background: We had to pause the video player project because there was not good answer for this yet.
Is there a better way to render units in the Learning MFE other than iframing the whole Django-rendered unit page?
Are there ways to render XBlocks that don't involve the Django backend at all?
Opinions
- Kyle: Backwards compatibility is important, upgrade path (+1 Braden)
- Brian S: Worry is frontend dependencies
- Dave: Challenges the assumption that bundling libraries in XBlocks is necessarily bad thing: what is the actual impact?
  - Long-term maintenance: we shouldn’t have to touch/worry about existing blocks
- Braden: One react version for core blocks (could be bundled with mfes), but full isolation for third party blocks.
- Ed: 400kB of download per block may not be a huge concern in some scenarios, but it can be in others
- Brian S: how stable is the API for any given block
  - Braden: XBlocks already presume Mathjax/Jquery/etc/etc are already present in the environment, and these APIs are not necessarily stable - it would be nice to get rid of them, even if the price is adding a single one such as React
  - Dave: people treat XBlocks as “little applications”, as opposed to APIs that need to be versioned/maintained. It would be a hard sell to have stable APIs.
  - Braden: lack of contract of XBlock API, whether runtime, frontend, or backend. “If in Studio this”, “If in LMS, that”. Going forward, would be good to have an API defined in code instead of just convention.
  - Ed: what is the current contract/convention?
    - Dave: the contract is nothing. You´re only guaranteed what you provide in the block itself.
- Feanil: Writing good user interfaces with what we have now is a pain
  - Dave: XBlocks do not have sufficient isolation
  - Feanil: opt in to isolation:
- Braden: not all XBlocks will need React
- …
- Braden: straw solutions
  - Legacy block? We inject what it expects
  - New block? In an iframe
- Feanil: building in sandboxing from the get go? Yes
Why is the unit-level iframe in Learning MFE bad?
- Adolfo: React Video player perspective: How to render? In the old code, you get a React dependency, bit of the old world rendering bit of the new, but not MFE–this is Django still.
  - So what do we do about the learner view? It’s already in an iframe in a Unit page in an MFE. What are the options?
    - Can bundle in React with the XBlock and incur UX penalties?
    - Can go the iframe + MFE approach like ORA → iframe in an iframe
    - RG was exploring what else we could do besides that. How do we get the video player in React inside? Outside the iframe?
    - Complicating things.
Kyle: How do you mix modes in the existing MFE iframe?
- Braden is assuming there is no Unit iframe any longer.
…
Brian S: do we want to use iframes/sandboxing? How about web components?
Dave: XBlocks as backend-only is a hard sell
- Is strongly in favor of sandboxing, though not necessarily nested iframes
Braden: XBlock development has stagnated - not many new XBlocks these days
- Kyle: Sandboxing is necessary for ProblemBlock and HTMLBlock because authors can add stuff.
- Feanil: Hard to predict when some old blocks will need upgrading, like FeedbackBlock.

Existing information: