Ich ventiere hier nur, aber nachdem ich mehr Templating-Sprachen verwendet habe, als ich mir gerne vorstellen möchte (Jinja2, ERB, FTL, XSLT, JSX, Handlebars usw.), finde ich Hyperscript absolut schrecklich in der Handhabung.
In keiner besonderen Reihenfolge, die Dinge, die es kaputt macht, sind:
Code-Portabilität (man kann HTML-Snippets nicht kopieren/einfügen, ohne sie durch einen Konverter laufen zu lassen)
Syntax-Hervorhebung (verwandelt alles in einen riesigen Klumpen), z. B.
Ja, ich stimme zu, dass es nicht die beste Wahl ist, besonders im Vergleich zu Handlebars (das wir ebenfalls verwenden), wo man HTML so schreiben kann, wie man es erwartet.
Wir haben virtual-dom/virtual-hyperscript an Stellen eingesetzt, an denen wir die Leistung verbessern mussten. Das Thema unserer mehreren Templating-Systeme haben wir kürzlich im Team diskutiert; wir haben noch keine konkreten Pläne, erkennen aber, dass eine Vereinfachung sinnvoll wäre. Vielleicht bedeutet das, dass wir virtual-hyperscript nicht mehr verwenden? Die Zeit wird es zeigen.
Die Syntax ist etwas gewöhnungsbedürftig. Ich erinnere mich, dass ich am Anfang beim Schreiben von Discourse-Themen damit ziemlich überfordert war, aber ich habe schließlich herausgefunden, wie sie funktioniert. Es ist auch möglich, über Widgets rohes HTML zu generieren.
Ich bin nicht der Beste darin, zu sagen, wann und wo man was verwendet, aber es ist eine Option, die du in Betracht ziehen kannst, wenn du eigene Anpassungen vornimmst, ein Widget schreiben musst und Schwierigkeiten mit virtual-hyperscript hast.
Das ist eine gute Erkenntnis – danke! Ich habe ein oder zwei Stunden damit verbracht, HTML-Fragmente manuell umzuschreiben, aber zwischen diesem Tool und html2hyperscript habe ich jetzt ein paar Optionen, mit denen ich spielen kann
Interessant… Ich dachte, einer der großen Vorteile von Ember sei die Geschwindigkeit der GlimmerVM. Ist die Leistung von virtual-dom ein so großer Fortschritt gegenüber Glimmer?
Verstehe. Dieser Zeitplan hilft – danke! Ich nehme also an, der einfachste Weg wäre, zu warten, bis die Glimmer-Performance der von virtual-dom entspricht, sie dann zu verwerfen und zu reinem Ember zurückzukehren?
Diese Funktion ist cool, aber ich habe Probleme, sie zum Laufen zu bringen. Ich habe discourse/widgets/hbs-compiler mit require eingebunden, bekomme aber immer noch den Fehler error: hbs is not a function.
Ich habe versucht, Vorlagen innerhalb von Widgets zu verwenden, stellte aber fest, dass dies ohne erkennbare Unterstützung für Helfer nur begrenzt nützlich ist:
Das war ärgerlich, da man dann bestehenden Standardcode an anderer Stelle im Codebase nicht wiederverwenden konnte.
Wir beschäftigen uns derzeit mit der Frage, wie wir unsere Templating-Systeme rationalisieren können. Ich werde mich in den nächsten Tagen damit befassen und dir eine Antwort auf dein spezifisches Problem geben.
Ja, der Übergang könnte etwas knifflig werden. Grundsätzlich könnten wir das Reverse-Äquivalent von html2hyperscript bauen, aber in der Praxis ist die meisten Hyperscript wahrscheinlich so eng mit dem JS des Widgets verflochten, dass es schnell zum Albtraum werden könnte.
Ich denke, die einfachste Lösung wäre, die Hyperscript-Unterstützung für eine Weile beizubehalten und sie vielleicht später schrittweise einzustellen.
Ich würde tatsächlich eher das Gegenteil sagen: Dass wir unsere Template-Nutzung vor Octane rationalisiert haben, wird uns helfen, später einfacher auf die Angle-Bracket-Syntax umzusteigen, wenn wir das möchten.
@edL Ich sehe withPluginApi in deinem Backtrace – versuchst du, den hbs-Compiler innerhalb eines <script>-Tags eines Themes zu verwenden? Leider funktioniert der Widget-Handlebars-Compiler in diesem Szenario nicht.
