Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

React Support for XBlock frontends

Abierto
  • ¿Algo no está bien?
#635 2 comentarios 1 reacción 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
20/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
python, react
Área
backend, frontend

Línea de trabajo

Comienza con el issue 634 de XBlock enlazado y, a continuación, revisa la rama del hackathon anterior de frontend-app-learning y el documento de decisiones de frontend-lib-content-components. El issue plantea preguntas de arquitectura sobre el descubrimiento de paquetes, el renderizado mixto de legacy y React, la seguridad y la compatibilidad, pero no define una implementación concreta ni una prueba de finalización; esas decisiones tendrían que resolverse antes de programar.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

epic

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
Lenguaje dominante
Python
Estrellas
470
Forks
231
Merge medio
2 d 14 h
PR fusionados (30 d)
7

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de openedx/XBlock

Todos los issues de openedx/XBlock

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.