In a Discourse development discussion, users explore the difference between .hbs and .raw.hbs (or .hbr) Handlebars templates. net_deamon notes that some plugin outlets (like topic-list-after-title) use {{raw-plugin-outlet}}, requiring .raw.hbs files, while others use {{plugin-outlet}} with standard .hbs files. sam clarifies that raw templates are a performance optimization—they lack full Ember lifecycle features like setupComponent, making them faster but less flexible. spirobel asks about alternatives to setupComponent and computed properties in raw templates; they later find a workaround by reopening models to add computed properties accessible in .raw.hbs. merefield questions whether raw templates can be backed by JavaScript components like regular ones. They discover that some components (e.g., topic-list-item) use .hbs templates that render .hbr templates via JavaScript, suggesting raw templates don’t directly support JS unless manually bridged. markvanlan recommends using helpers for JS logic in raw templates, citing an example from the discourse-category-experts plugin. merefield reports switching some .hbr to .hbs to enable closure actions for passing data up the component tree, despite performance trade-offs. markvanlan and merefield discuss whether helpers can handle upward data flow, with merefield noting the need to persist computed image properties from leaf components to grandparent for styling. In summary, raw templates offer speed but limited interactivity; JS logic must be added via helpers or model extensions, or avoided by using full .hbs components when complex data flow is needed.
Is there something similar to setupComponent(args, component) with the raw outlets as well? What about computed properties? I would like to do some computations based on the data in context. How can I go about this? I dont even know if I named my accompanying .js.es6 file right. Should I name it .raw.js.es6?
Is it possible to ‘back’ a raw template with corresponding javascript as per regular Components, within a Theme Component.
I’ve got quite a challenging use-case and I need to manage actions to pass arguments back up the component chain from a deeply embedded template within the topic list.
I note there are several .hbr files with apparently corresponding Javascript Component elements in the Discourse source but noticed something odd, e.g.:
In some recent work, I’ve needed some of the template “tree” to be able to communicate data up from a leaf template using closure actions, so I’ve switched some of the hbr’s to hbs’s to support his.
The work is experimental and I appreciate this will have a performance impact, but after iterating the design a few times was unable to find an alternative way of doing this whilst keeping “in-framework”.
Specifically, I’m determining properties of an image in a leaf component, then storing them as properties of the grandparent to influence styling that must persist beyond the current list render. The data definitely has to pass up. If a helper can achieve that that sounds like a good option if I get stuck with current approach, thanks!
