Mi sfogo solo qui, ma dopo aver usato più linguaggi di templating di quanti io voglia ricordare (Jinja2, ERB, FTL, XSLT, JSX, Handlebars, ecc.), trovo Hyperscript assolutamente terribile da usare.
In nessun ordine particolare, le cose che si rompono includono:
Portabilità del codice (non puoi copiare/incollare frammenti HTML senza passarli attraverso un convertitore)
Evidenziazione della sintassi (trasforma tutto in un enorme blocco) ad esempio
Sì, concordo che non sia il migliore con cui lavorare, specialmente rispetto a Handlebars (che usiamo anch’esso), dove puoi scrivere HTML come ti aspetti.
Abbiamo iniziato a utilizzare virtual-dom/virtual-hyperscript nei punti in cui era necessario migliorare le prestazioni. La questione dei nostri sistemi di templating multipli è qualcosa di cui abbiamo iniziato a discutere recentemente nel team; non abbiamo ancora piani concreti, ma siamo consapevoli che sarebbe una buona idea semplificare. Forse questo significa che non useremo più virtual-hyperscript? Il tempo lo dirà.
La sintassi è un po’ strana da abituarsi. Ricordo di essermi sentito molto confuso quando ho iniziato a scrivere temi per Discourse, ma alla fine ho capito come funziona. È anche possibile generare HTML grezzo tramite widget.
Non sono il più esperto nel dire quando e dove usare cosa, ma è un’opzione da considerare se stai facendo lavori personalizzati, devi scrivere un widget e hai difficoltà a usare virtual-hyperscript.
Ne vale la pena, grazie! Ho passato un’ora o due a riscrivere manualmente i frammenti HTML, ma con questo e html2hyperscript ho un paio di opzioni da provare
Interessante… pensavo che uno dei grandi vantaggi di Ember fosse la velocità di GlimmerVM. Le prestazioni di virtual-dom sono davvero un tale miglioramento rispetto a Glimmer?
Capisco. Questa timeline aiuta, grazie! Quindi, suppongo che la strada più semplice sia attendere che le prestazioni di Glimmer siano equivalenti a quelle di virtual-dom, poi eliminarlo e tornare a Ember puro?
Questa funzione è fantastica, ma ho qualche difficoltà a farla funzionare. Ho fatto require di discourse/widgets/hbs-compiler, ma ricevo comunque l’errore error: hbs is not a function
Ho provato a utilizzare i template all’interno dei widget, ma ho scoperto che la loro utilità è limitata a causa della mancanza di supporto apparente per gli helper:
Ciò è stato fastidioso, poiché non era possibile riutilizzare il codice standard esistente altrove nella codebase.
Stiamo attualmente facendo brainstorming su come razionalizzare i nostri sistemi di templating. Approfondirò l’argomento e ti fornirò una risposta al tuo problema specifico nei prossimi giorni.
Sì. La transizione potrebbe essere un po’ delicata. In linea di principio, potremmo costruire l’equivalente inverso di html2hyperscript, ma in pratica, la maggior parte di hyperscript è probabilmente così intrecciata con il js del widget che potrebbe rapidamente diventare un incubo.
Immagino che la soluzione più semplice sia mantenere il supporto per hyperscript per un po’ e forse deprecarlo in un secondo momento?
Direi piuttosto il contrario: aver razionalizzato l’uso dei nostri template prima di Octane ci aiuterà a migrare più facilmente alla sintassi con angoli quando vorremo farlo.
@edL Vedo withPluginApi nel tuo backtrace: stai cercando di utilizzare il compilatore hbs all’interno di un tag <script> del tema? Purtroppo, il compilatore Handlebars per i widget non funziona in questo scenario.
Devi definire il widget in un modulo separato utilizzando le istruzioni import che @j.jaffeux ha incluso sopra. Puoi farlo in un tema sfruttando il supporto per JavaScript multi-file.
