Discourse-Themenkomponenten unterstützen jetzt Wasm 🎊

WebAssembly (Wasm) ist eine Technologie, die in allen modernen Browsern verfügbar ist und es Entwicklern ermöglicht, portable Binärprogramme auszuliefern.

Dies bedeutet, dass Entwickler fast jede Programmiersprache verwenden und das Web als Ziel haben können.

Im Kontext von Discourse eröffnet dies die Möglichkeit, eine ganze Reihe von Erweiterungen auszuliefern, die in der Vergangenheit nur für Plugin-Ersteller verfügbar waren.

Beispiele hierfür könnten sein:

• Bild-Wasserzeichen / -Größenänderung / -Zuschneidung
• Graph-Generierung mit graphviz oder svgbob
• Programmier-Sandboxes (z. B. Beiträge, die eine Ruby-Laufzeitumgebung einbetten)
• und vieles mehr

In der Vergangenheit wurde aufgrund der Discourse Content Security Policy der Zugriff auf Wasm gesperrt, außer bei Installationen mit lokalen Uploads und ohne CDN.

Neue Schnittstellen wurden auf der Client-Seite hinzugefügt, um die Auslieferung von JavaScript-Assets in einem Theme zu unterstützen, die über die lokale Domain bedingungslos erreichbar sind.

Dies ermöglicht Theme-Entwicklern, Wasm sauber zu hosten. Der Ablauf ist:

Komponente → lokaler Web Worker → Wasm gehostet auf CDN

Discourse svgbob ist ein End-to-End-Beispiel für die neuen Muster. Die 2 wichtigsten Änderungen sind:

1. Alle .js-Assets werden auch abseits des CDN auf dem lokalen Server verfügbar gemacht:

{
...
  "assets": {
    "worker": "assets/will-be-avilable-on-local.js"
  }
}

2. Die URL für das lokale Asset ist über settings.theme_uploads_local zugänglich.

Im obigen Beispiel also:

settings.theme_uploads_local.worker; // lokales Asset
settings.theme_uploads.worker; // CDN-Asset

Nicht speziell wasm-bezogen, aber ich habe etwas anderes Interessantes an diesem Code gefunden, ist das neu?

In Ihrem Beispiel ist loadScript nicht mehr erforderlich? (Ich glaube, der Import ist überflüssig?):

und stattdessen wird das Worker-Skript JIT geladen, wenn festgestellt wird, dass der Worker nicht existiert?

unter Verwendung der URL, die aus der Asset-Referenz erstellt wurde.

Das ist ein schönes Muster und sehr hilfreich!

Ich habe jedoch eine Frage zu Workern.

Wenn ich ein Drittanbieter-Worker-Skript verwenden würde, das importScripts()-Anweisungen enthält, um zusätzliche Skripte in den globalen Geltungsbereich des Workers einzubinden, wie binde ich diese Skripte für den Import in der Theme-Komponente ein?

Ich frage vielleicht: Wie fordere ich ein Skript von einer URL innerhalb einer Discourse-Theme-Komponente an?

Was ich in diesem Szenario getan habe, ist die Verwendung von postMessage aus dem Haupt-JS-Skript mit den zu importierenden URLs. Dies wird im Nachrichtenhandler des Workers empfangen, der die empfangenen URLs mit importScript importieren kann.

Danke Rafael! Haben Sie ein Open-Source-Beispiel als Referenz?

Ich habe dieses gleiche Muster im Kern verwendet

Ich benutze den Theme Creator, um eine neue Theme-Komponente zu erstellen, die wasm verwenden soll. Als Ausgangspunkt habe ich versucht, svgbob als Theme-Komponente hochzuladen. Das ist mir jedoch nicht erlaubt, da es eine wasm-Datei enthält.

Ist das eine beabsichtigte Einschränkung des Theme Creators? Oder kann man svgbob nicht einfach so installieren?

Ich vermute, dass wir nur eine Dateitypbeschränkung im Theme Creator haben, die aufgehoben werden muss.

Ich habe themecreator zurückgesetzt, um die Standardeinstellung „theme authorized extensions“ zu verwenden, die WASM einschließt. Es sollte jetzt funktionieren, @Heinenen.

(Ich bin mir nicht sicher, warum es auf einer nicht standardmäßigen Einstellung war… vielleicht fehlte in der Vergangenheit eine der gängigen Erweiterungen )

Ja, sehr cool, ich kann bestätigen, dass es jetzt funktioniert. Danke!

Okay, es scheint, dass ich ein wenig zurückrudern muss, ich glaube nicht, dass es noch perfekt funktioniert.
Ich habe versucht, svgbob erneut hochzuladen, und das hat funktioniert.

Nachdem ich nun auch versucht habe, meine eigene wasm-Datei hochzuladen, die von MDN stammt, erhalte ich die Fehlermeldung:
Ein Fehler ist aufgetreten: Sie haben ungültige Parameter für die Anfrage angegeben: String enthält Null-Byte

Auf meinem Entwicklungscontainer ist dies kein Problem und ich kann dieselbe Datei problemlos hochladen.

Ist es nicht ein Sicherheitsrisiko, eine Binärdatei von der Website auszuführen, das sorgfältig abgewogen werden sollte? Das könnte ein Grund sein, warum es nicht standardmäßig eingestellt war. Was denkst du, @Roman?

Es ist in Themes standardmäßig erlaubt. Es ist nur die Website-Einstellung auf discourse.theme-creator.io, die geändert wurde. (Das ist eine normale Discourse-Website mit einem Plugin, das es jedem erlaubt, Themes hochzuladen und zu teilen).

WASM ist immer noch vom Browser isoliert, daher ist die Sicherheitslücke gleichwertig mit einer .js-Datei.