Llevo tiempo con una idea rondándome: modernizar el frontend de mi plugin de Moodle. Hoy genera HTML en el servidor y recarga la página para cualquier cosa. Quiero que la interfaz reaccione —que cambie sola cuando cambian los datos, sin recargar—.

El primer paso ya lo di, y lo conté en el episodio del podcast «Datos, no comportamiento»: el servidor dejó de fabricar páginas y pasó a exponer datos a través de Web Services. Ese es el cimiento. Lo que faltaba era decidir quién pinta esos datos en el navegador. Y la respuesta, esta vez, no la pongo yo: la ha puesto Moodle.

Moodle ha elegido React #

Durante años, Moodle fue deliberadamente agnóstico con el frontend: “usa el framework que quieras”. Tenía incluso su propia librería reactiva, core/reactive —la que mueve el Course Index—, pero no imponía nada.

Eso ha cambiado. Moodle 5.2 mete React en el core. Es el primer hito de su hoja de ruta de 2026 (junto con Composer y la observabilidad con OpenTelemetry), y la intención es clara: React pasa a ser el framework de interfaz de Moodle. La meta de fondo es que el frontend evolucione independiente del backend, con plugins más fáciles de desplegar.

No es un rumor ni una preferencia mía: es la dirección declarada del proyecto. Y eso, para quien mantiene un plugin, lo cambia todo.

Qué significa para un plugin #

Cuando el core elige una tecnología, tienes dos caminos: alinearte o acumular deuda. Un plugin que siga fabricando HTML desde el servidor mientras Moodle se mueve hacia componentes React quedará cada año un poco más lejos del resto de la plataforma —más raro de mantener, más difícil de encajar—.

Yo prefiero ir por donde va el core. No porque React sea mágico, sino porque hablar el idioma de la plataforma en la que vives es, a la larga, lo más barato.

Cómo es React dentro de Moodle #

Lo bueno de que React entre en el core es que no tienes que inventarte el montaje: Moodle ya trae el camino. A grandes rasgos:

• Tu código React vive en el plugin, en js/esm/src/, escrito en TypeScript (TSX), y se compila con el build de Moodle (grunt react, que por debajo usa esbuild). El bundle generado acaba en js/esm/build/.
• Se monta desde una plantilla Mustache. Escribes un bloque que declara el componente y sus datos iniciales, y Moodle lo monta solo en la página:

{{#react}}{
    "component": "@moodle/lms/mod_miplugin/viewer",
    "props": { "sessionid": {{sessionid}} }
}
<p>Cargando…</p>
{{/react}}

• React no engorda tu plugin. react y react-dom los aporta el propio Moodle, así que no se empaquetan en tu bundle.
• Los datos siguen viniendo de Web Services, llamados con core/ajax. Es decir: el refactor que ya hice —servir datos en vez de HTML— es exactamente el motor que React necesita por debajo. El cimiento estaba puesto.

El HTML inicial lo pinta Mustache (rápido, accesible, bueno para SEO); a partir de ahí, el componente React toma el control y solo actualiza lo que cambia.

La parte honesta #

Dos cosas, para no vender humo:

Una, React en Moodle es muy reciente. Llega con la 5.2, las bases acaban de volverse usables de verdad, y el propio Moodle recomienda auditar la compatibilidad antes de llevar nada a producción. Esto es subirse pronto, con lo que eso tiene de bueno (vas por delante) y de incómodo (hay menos ejemplos y más aristas).

Y dos, todavía no lo he migrado, y aún no domino React. Este post es el mapa, no la crónica de la batalla. Tengo el cimiento (los Web Services), tengo el destino (React, porque es donde va Moodle) y tengo que aprender el camino. El plan: coger un trozo pequeño del plugin —no todo de golpe— y convertirlo en un componente React de verdad.

Para empezar, el punto de partida es la guía oficial de React en Moodle.

Iré contando cómo va —incluidos los tropiezos, que con algo tan nuevo los habrá—. Pero la decisión grande ya no es mía: Moodle ha elegido React, y lo más sensato es ir detrás.