React Support for XBlock frontends

Goal

Full completion would mean:

• Give XBlock developers access to the same modern frontend framework (React) and accessible component library (Paragon) that micro-frontend developers use.
• Support all views: student, public, author, and studio.
• Equally support all blocks, including the ones in edx-platform (eg, problem) and the ones in other repositories (eg, lti_consumer). This means that the new React views cannot be baked into core repositories.
• Retain parallel support for existing edx-platform-rendered XBlock frontends.
• Avoid regressions in performance, accessibility, i18n, or security.

Non-goals:

• A new JS-based courseware plugin system separate from XBlock. This is an interesting idea, and has explored in the "NeXBlock" writeup. For this epic, though, we're interested in evolving the existing XBlock ecosystem.
• Supporting blocks above the unit level, eg sequence. The established direction of edx-platform is that XBlocks should be used to customize courseware within the unit, but customizations to course structure should be left to separate, declarative systems.

Prior Work

Enhanced editors for Text, Video, and Problem

https://github.com/openedx/frontend-lib-content-components/blob/main/docs/decisions/0003-V2-Content-Editors.rst

Hackathon: React HTML block student view

Hackathon: React HTML block student view

We (@nsprenkle & @muselesscreator) worked on a proof of concept during a hackaton project. Note that the actual APIs we are calling are probably not the way we want to do this and we also dangerously set inner HTML of a block on the page, but the valuable bit here is we played with having multiple types of render logic from the Learning MFE,

Source: https://github.com/openedx/frontend-app-learning/tree/bw/hackathon

The TL;DR of how we think this should work:

1. Add frontend components for (or all) of the native edx-platform XBlocks to the Learning MFE. Others could be installed the way we install other frontend components (e.g. Header / Footer)
2. Create a list of frontend-renderable XBlocks supported by the Learning MFE (we've been calling these FRend blocks).
3. Update the XBlock backend with an endpoint for returning JSON data, instead of HTML using the xblock.json_handler functionality. An option is to use the student_view_data paradigm used in some other environments (e.g. mobile app).
4. When the Learning MFE looks at a unit, it identifies if some/all of the content is frontend-renderable (FRendly).
5. Up for debate on the best rendering scheme, whether we only drop to frontend rendering only when all blocks are FRendly, or a majority, or while under some threshold for un-FRendly blocks on a page.
6. For each FRend XBlock on the page (or with some other bulk retrieval scheme), call the data endpoints on those XBlocks for the data to render those blocks, render at the block level.
7. For remaining un-FRendly blocks, create iframes to render the individual/grouped blocks HTML.

Note that this should also probably be configurable per-course as some hacky (but desired by course staff) behavior could be lost with this new pattern.

Other things we learned

1. A similar pattern was investigated during the development of the Learning MFE, but was dropped because it was considered too challenging to implement all supported XBlock frontends. This option is more iterative and allows us to continue iframeing old-style HTML XBlocks while we implement frontends for the more common components.
2. The iframe sandbox is both a blessing and a curse. This adds security and separation from the course material and our course chrome but doesn't give us access to that course content from the Learning MFE, blocking features like context-aware annotations.
3. There is an iframe performance overhead that gets progressively worse for multiple iframes on a page. Suggestion was to think of a rendering scheme that defers to old style unit rendering if there would be too many iframes rendered to the page.
4. Course staff have lots of interesting hacks and tweaks to XBlocks including custom JS that cross communicate between blocks. I argue this is a bad idea, but staff seem to like it and it is a competitive differentiation. Suggestion was to allow opt in/out for a course / org.

Considerations & Open Questions

• Where do the React frontends live?
  • As an NPM package in the same repository as the XBlock backend?
• How would the MFEs (learning, course-authoring, library-authoring)...
  • discover & install the correct NPM packages for all installed XBlocks types?
  • discover & load the correct JS modules with the frontend React components?
• How do we handle units with a mix of legacy and React-enabled blocks?
  • Fall back to legacy views?
  • Group legacy blocks into views, something like this?

  <Unit>
    <iframe>
      <legacy-block ... />
      <legacy-block ... />
    </iframe>
    <ReactEnabledBlock/>
    <iframe>
      <legacy-block ... />
      <legacy-block ... />
    </iframe>
    <ReactEnabledBlock/>
  </Unit>
  

• Currently, XBlocks in the same unit can "talk" to one another with JS. Would React-enabled blocks support that? If not, is it OK to break that?
• Security: Currently, the unit iframe sandboxes instructor-authored XBlock content to a certain extent, protecting site from courseware script injection. How do we retain that security when rendering React-enabled blocks directly into the Learning MFE?
• Should we worry about drift between legacy frontends and React frontends?
• Would we ever deprecate legacy block frontends?
• This whole proposal assumes React as a framework. Should we avoid that assumption?

Tasks

### Tasks
- [ ] https://github.com/openedx/XBlock/issues/634

Start with the linked XBlock issue 634, then review the prior frontend-app-learning hackathon branch and the frontend-lib-content-components decision document. The issue lists architecture questions about package discovery, mixed legacy and React rendering, security, and compatibility, but does not define a concrete implementation or completion test; those decisions would need to be resolved before coding.