JavaScript in Attempts ermöglichen

[MartinGauk]

• Innerhalb des Attempts kann das Paket per call_js(module, function, data, if_role_feedback) veranlassen, dass das LMS im Browser eine JS-Funktion aufrufen soll.
• module kann aktuell nur als volle Referenz in der Form @[package namespace]/[package short name]/[subdir]/[module name] angegeben werden
• Das static-files example wird erweitert um ein simples JS-Beispiel.
• JS wird mittels RequireJS geladen, d.h. das JS muss vom Paket als AMD-Modul bereitgestellt werden. Auch wenn RequireJS als out gilt, bietet es gerade in unserem Fall große Vorteile:
  • Dank des Multiversion Supports können wir RequireJS auf einer Seite mehrfach instanziieren und auf diese Weise problemlos mehrere Fragen anzeigen lassen, auch wenn die einzelnen Fragen Abhängigkeiten zu unterschiedlichen Versionen haben sollten.
  • Durch die paths Einstellung können wir sehr leicht bestimmen, welches Modul von wo geladen werden soll und das Laden aus den Attempt files ermöglichen und Paket-Hashes in die URL einbauen.
  • ES6 Module und importmaps sind für uns nicht so gut machbar, da auf einer Seite nur eine importmap erlaubt ist und im Zusammenspiel mit dem LMS das irgendwann zu einem Problem führen könnte bzw. das Anzeigen mehrerer Fragen erschwert.

Abhängig von questionpy-org/questionpy-server#120

[MHajoha]

| tojson wäre hier einfacher und laut Doku auch "safe to render in HTML documents and <script> tags."

[MHajoha]

Auf den ersten Blick scheint das HTML-Autoescaping von Jinja zwar zumindest naive Injection ("\"böserCode()") zu verhindern, verändert dabei aber die Strings auch inhaltlich. Das ist vermutlich praktisch selten ein Problem, wir können aber recht simpel | tojson verwenden, da kommt dann ein korrekt escapter JS(ON)-String raus.

[MHajoha]

"Keine Daten" würde ich lieber auch im Model mit None darstellen als mit dem leeren String, auch wenn das vermutlich nur stilistisch ist.

[tumidi]

JavaScript von externen Anbietern einzubinden halte ich für problematisch und unnötig.

• Datenschutz: CDNs können Verbindungen unkontrolliert an Staaten außerhalb der EU weiterleiten. Das ist ein Datenschutzproblem und ist im Zweifel nicht DSGVO-konform.
• Setzt aktive Internet-Verbindung vorraus (z.B. jemand der im Zug arbeitet o.ä. ist außen vor).
• Security: Legt die Verantworung effektiv in die Hand eines externen Anbieters. Kompromittierte CDNs hat es schon gegeben...
• Downtimes: Es hat in der Vergangenheit CDN-Downtimes gegeben.

Im Allgmeinen auch unnötig, da es Alternativen gibt:

• RequireJS gar nicht erst nutzen (siehe anderen Kommentar)
• Die JS-Datei direkt ins Projekt schreiben (wäre hier m.M.n. die pragmatische Lösung, wenn an RequireJS festgehalten wird)
• (NPM verwenden) - kommt ja wahrscheinlich eh bald mit dem neuen Frontend

[MartinGauk]

Ich bin auch kein Fan von CDNs, aber vor dem Hintergrund der angehenden kompletten JS-Umstrukturierung ist das eine pragmatische Zwischenlösung. Später sollte das beim Bundlen direkt mitgeliefert werden.

Bezüglich RequireJS habe ich eingangs mehrere Gründe genannt. Ich denke es bietet eine große Flexibilität für dynamische Abhängigkeiten. Dagegen sind ES6 und die Importmap leider viel zu statisch und andere moderne Alternativen für genau unseren Anwendungsfall mit den Fragepaketen sehe ich nicht.

[tumidi]

Ich habe starke Bauchschmerzen in einem neuen Projekt auf AMD/RequireJS zu setzen.

Dank des Multiversion Supports können wir RequireJS auf einer Seite mehrfach instanziieren und auf diese Weise problemlos mehrere Fragen anzeigen lassen, auch wenn die einzelnen Fragen Abhängigkeiten zu unterschiedlichen Versionen haben sollten.

Verschiedene Versionen innerhalb einer Seite zu laden ist grundsätzlich auch mit anderen Mitteln möglich: Dynamische Imports, Shadow DOM, Bundler.

Durch die paths Einstellung können wir sehr leicht bestimmen, welches Modul von wo geladen werden soll und das Laden aus den Attempt files ermöglichen und Paket-Hashes in die URL einbauen.

Am Ende des Tages kommen wir an einem Indirektionsschritt nicht vorbei, wenn wir ein "custom" Modulschema anbieten möchten, seien es importmaps, die Verwendung eines Bundlers oder eine andere Technik (wobei importmaps als natives Browserfeature das Mittel der Wahl wären).

ES6 Module und importmaps sind für uns nicht so gut machbar, da auf einer Seite nur eine importmap erlaubt ist und im Zusammenspiel mit dem LMS das irgendwann zu einem Problem führen könnte bzw. das Anzeigen mehrerer Fragen erschwert.

Multiple import maps kommen. Bis es soweit ist, müssen wir eben einen Workaround anbieten:

1. Die eines Nutzung Bundler voraussetzen bzw. vereinfachen (bspw. durch ein Projekt-Template und gute Doku),
2. Für Pakete ohne Build-Step, einen Wrapper qpyImport() anbieten, der das Mapping transparent erledigt, o.ä.
3. Einen Endpoint anbieten, der die gewünschten Informationen in die URL einbettet und die richtige Datei ausliefert.
   • Ich denke, das könnte mittels eines ServiceWorkers sogar transparent geschehen. (mehr Research nötig)
4. Der Vollständigkeit halber gäbe es auch die Möglichkeit, eine importmap im Backend zu mergen. Allerdings würde diese Lösung, Support im LMS/Application-Server voraussetzen (was bei Moodle aktuell nicht der Fall ist).

Argumente gegen RequireJS

• RequireJS ist überholt.
  • ES-Module sind die Zukunft, quasi 100% Browsersupport.
    • Ob man ESM nun mag oder nicht. Das ist die Realität.
  • RequiresJS wird seit ca. 12 Jahren nicht mehr aktiv weiterentwickelt.
  • RequireJS hat einen End-of-life-Status. (Aussage vom Maintainer)
  • AMD ist durch ESM quasi obsolet.
• RequireJS fügt zusätzliche Komplexität hinzu, ESM funktionieren nativ in Browsern.
• Der Trend geht zu "pure ES"-Paketen.
  • Immer mehr Libraries bieten ausschließlich ESM-Builds an.
  • QuestionPy-Pakete müssten eh einen Bundler o.ä. verwenden, um diese Projekte in RequireJS zu verwenden (was die Verwendung von RequireJS überflüssig macht, da Bundler eigene Modullader mitbringen).
• Entwickler*innen müssten ein veraltetes Modulsystem lernen, bspw. define-Semantik und -Syntax.
• Tree shaking ist nur mit ESM möglich.

Links

• Moodle Issue zu ES6: MDL-62495: Support for native ES6

[MartinGauk]

Grundsätzlich hast du in einigen Argumenten völlig recht, allerdings spielen in der Diskussion Tree Shaking, veraltetes Modulsystem lernen und Bundling keine Rolle. Das geschieht beim Bauen eines einzelnen Pakets. Es geht an der Stelle ausschließlich um die Fähigkeiten, im Client JS zu laden und die Abhängigkeiten zu verwalten. Und das sind Punkte, in denen RequireJS die flexibelsten Funktionalitäten bietet.

Multiple import maps kommen. Bis es soweit ist, müssen wir eben einen Workaround anbieten:

Ausgerechnet "Provide a programmatic way to expand or modify the Window’s import map" ist ein non-goal. :/

• QuestionPy-Pakete müssten eh einen Bundler o.ä. verwenden, um diese Projekte in RequireJS zu verwenden (was die Verwendung von RequireJS überflüssig macht, da Bundler eigene Modullader mitbringen).

Ich will RequireJS nicht als Bundler nutzen sondern nur als Lader auf der Client-Seite. Die Pakete sollen dynamische Abhängigkeiten zu anderen Paketen haben dürfen, womit auch das JS der anderen Pakete geladen können werden darf. Dem Bundler wird beim Paketbauen gesagt, dass es sich um eine externe Abhängigkeit handelt, d.h. auf der Client-Seite muss es dann einen Modullader geben.

---

Für den Aufruf einer JS-Funktion hatte ich zwischenzeitlich überlegt, dass ein Objekt von Attempt nicht als erstes Argument übergeben wird, sondern man das Objekt in sein Modul importiert. Dazu muss pro Frage ein dynamisches Modul erstellt werden, in dem sich das Objekt befindet. Das ist mit RequireJS problemlos möglich, weil man eine RequireJS-Instanz pro Frage erstellen kann und ein Modul nicht in einer einzelnen/realen Datei stecken muss. Bei ESM sehe ich dafür keine Chance.

---

Ich erstelle in Tefen gerade eine Übersicht, in der ich versuche die Einbindungsarten (direkt in DOM, Shadow DOM, iframe) zu vergleichen.

[tumidi]

Edit: Recherche zu Modulformat und -lader

Original post

Wollte hier meine aktuellen Gedanken/Notizen festhalten. Wir können aber gern auch auf dem nächsten Meeting in Person darüber reden, wenn das einfacher ist.

allerdings spielen in der Diskussion Tree Shaking, veraltetes Modulsystem lernen und Bundling keine Rolle. Das geschieht beim Bauen eines einzelnen Pakets.

Ich denke, diese Punkte werden für frontend-lastige QPy-Pakete potentiell durchaus eine Rolle spielen.

Gehst du von einem (impliziten) Transpilierungsschritt während des Paketbauens aus? Also, dass das SDK während des Bauens automatisch und transparent einen Bundler o.ä. verwendet?

Es geht an der Stelle ausschließlich um die Fähigkeiten, im Client JS zu laden und die Abhängigkeiten zu verwalten.

Die Themen sind verflechtet und lassen sich kaum unabhängig betrachten. Eine Entscheidung auf der einen Seite (JS im Client laden) hat ja Einfluss auf die andere Seite (in welchem Format JS-Quellen in QPy-Paketen vorliegen müssen), und andersherum.

Und das sind Punkte, in denen RequireJS die flexibelsten Funktionalitäten bietet.

Ich denke halt, RequireJS wäre (durch die Begrenzung auf AMD) weniger flexibel als ESM. QPy-Pakete wären effektiv dazu gezwungen eine JS-Build-Toolchain einzusetzen (siehe nächster Punkt).

• QuestionPy-Pakete müssten eh einen Bundler o.ä. verwenden, um diese Projekte in RequireJS zu verwenden (was die Verwendung von RequireJS überflüssig macht, da Bundler eigene Modullader mitbringen).

Ich will RequireJS nicht als Bundler nutzen sondern nur als Lader auf der Client-Seite. Die Pakete sollen dynamische Abhängigkeiten zu anderen Paketen haben dürfen, womit auch das JS der anderen Pakete geladen können werden darf. Dem Bundler wird beim Paketbauen gesagt, dass es sich um eine externe Abhängigkeit handelt, d.h. auf der Client-Seite muss es dann einen Modullader geben.

Vielleicht habe ich das schlecht ausgedrückt oder wir missverstehen uns.

RequireJS kann keine ES-Module verarbeiten, was problematisch ist, wenn wir es als Modullader voraussetzen.

Wenn QuestionPy die Verwendung von RequireJS/AMD erzwingt, hat das Konsequenzen. Beispiel: Die aktuelle Version von XY liefert kein UMD-Build mehr mit. Möchte nun ein QPy-Paket XY nutzen wäre die einzige Option, ein eigenes UMD-Build mit Babel oder einem Bundler wie Webpack zu erstellen.

Das aber setzt Wissen über Modulsysteme und JS-Tooling voraus, und nicht alle Projekte lassen sich problemlos in UMD umwandeln, da die beiden Modulssysteme unterschiedliche Semantiken haben. Dieses Problem wird noch zunehmen, da immer weniger Projekte UMD-Builds anbieten.

Alternative: SystemJS

Ich denke, wenn wir einen Modullader clientseitig einsetzen, sollten wir uns SystemJS als Alternative zu RequireJS anschauen.

• Eigenes Modulformat
  • Bildet 1:1 ESM-Semantik ab, ES-Module müssen aber zur Build-Time transformiert werden.
  • Unterstüzt AMD direkt (ohne Transformation)
• Mehrere isolierte Instanzen des Modulladers möglich
• Unterstützung für Importmaps
  • Auch mehrere
  • Auch dynamisch
• Bietet flexible Loader-Hooks
  • Damit lässt sich das Verhalten des Loaders anpassen, z.B. als Alternative zu Importmaps.
• Von Webpack u. Rollup aus Ausgabeformat unterstützt.
• Unklar wie SystemJS auf einer Seite funktioniert, wo schon RequireJS aktiv ist (was bei Moodle ja der Fall ist), aber sollte eig. kein Problem sein.

Edit: Ein weiterer Punkt ist ja die Verwendung von Moodle (bzw. allgemein die Verwendung von LMS-JS-Komponenten, wie dem Filepicker oder Editor). Ich denke, SystemJS wäre hier flexibel genug, die entsprechenden Objekte "einzusammeln" und den Fragen unter einem "virtuellen" Modulnamen anzubieten.