Je me défoule juste ici, mais après avoir utilisé plus de langages de templating que je ne voudrais m’en souvenir (Jinja2, ERB, FTL, XSLT, JSX, Handlebars, etc.), je trouve Hyperscript absolument horrible à utiliser.
Sans ordre particulier, voici les problèmes qu’il engendre :
Portabilité du code (impossible de copier/coller des extraits HTML sans les passer par un convertisseur)
Coloration syntaxique (transforme tout en un gros bloc informe) par exemple
Oui, je suis d’accord, ce n’est pas l’idéal pour travailler, surtout par rapport à Handlebars (que nous utilisons également), où vous pouvez écrire du HTML comme vous l’attendez.
Nous avons commencé à utiliser virtual-dom/virtual-hyperscript dans les endroits où nous devions améliorer les performances. Le sujet de nos multiples systèmes de templating est quelque chose dont nous avons commencé à parler récemment au sein de l’équipe ; nous n’avons pas encore de plans concrets, mais nous réalisons qu’il serait bon de simplifier. Peut-être que cela signifie que nous n’utiliserons plus virtual-hyperscript ? Le temps nous le dira.
La syntaxe est un peu étrange à prendre en main. Je me souviens avoir été vraiment dérouté au début quand j’ai commencé à écrire des thèmes pour Discourse, mais j’ai fini par comprendre comment cela fonctionne. Il est également possible de générer du HTML brut via un widget.
Je ne suis pas le plus à même de dire quand utiliser quoi et où, mais c’est une option à envisager si vous effectuez un travail personnalisé, devez écrire un widget et rencontrez des difficultés avec virtual-hyperscript.
C’est utile à savoir — merci ! J’ai passé une heure ou deux à réécrire manuellement des fragments HTML, mais entre cela et html2hyperscript, j’ai quelques options à explorer
C’est intéressant… Je pensais que l’un des principaux avantages d’Ember était la vitesse du GlimmerVM. La performance du virtual-dom est-elle vraiment une telle amélioration par rapport à Glimmer ?
Je vois. Cette chronologie est utile — merci ! Donc, je suppose que la solution la plus simple serait d’attendre que les performances de Glimmer soient équivalentes à celles de virtual-dom, puis de l’abandonner et de revenir à Ember pur ?
Cette fonctionnalité est géniale, mais je rencontre des difficultés pour la faire fonctionner. J’ai require’d discourse/widgets/hbs-compiler, mais j’obtiens toujours l’erreur error: hbs is not a function
J’ai essayé d’utiliser des modèles dans les widgets, mais j’ai constaté que cela avait une utilité limitée en raison de l’absence apparente de prise en charge des helpers :
C’était frustrant, car vous ne pouviez pas réutiliser le code standard existant ailleurs dans la base de code.
Oui, malheureusement, je pense que tenter d’utiliser Handlebars au lieu de Hyperscript est actuellement plus problématique que cela n’en vaut la peine.
Nous réfléchissons actuellement à la manière d’unifier nos systèmes de modèles. Je vais examiner cela et vous apporter une réponse à votre problème spécifique dans les prochains jours.
Oui. La transition pourrait être un peu épineuse. En principe, nous pourrions créer l’équivalent inverse de html2hyperscript, mais en pratique, la plupart du code hyperscript est probablement si étroitement lié au JavaScript du widget que cela pourrait rapidement devenir un cauchemar.
Je suppose que la solution la plus simple est de maintenir le support d’hyperscript pendant un certain temps, et peut-être de le déprécier par la suite ?
Je dirais même plutôt le contraire : le fait d’avoir rationalisé l’utilisation de nos modèles avant Octane nous aidera à migrer plus facilement vers la syntaxe des balises angulaires lorsque nous le souhaiterons.
@edL Je vois withPluginApi dans votre trace d’erreur - essayez-vous d’utiliser le compilateur hbs à l’intérieur d’une balise <script> d’un thème ? Malheureusement, le compilateur Handlebars des widgets ne fonctionne pas dans ce cas.
Vous devez définir le widget dans un module séparé en utilisant les instructions import que @j.jaffeux a incluses ci-dessus. Vous pouvez le faire dans un thème en utilisant le support JavaScript multi-fichiers.
