Yes, something similar to Temple would technically be possible for Hologram in the future. The core of what Hologram’s template/0 does is generate an anonymous function that:
Receives variables (state and props)
Returns a nested Elixir data structure representing the DOM
Can be transpiled to JavaScript for virtual DOM rendering
So theoretically, different template syntaxes could be implemented as long as they produce this same kind of anonymous function with the proper nested data structure.
However, implementing this right now would be quite challenging because the template system is tightly coupled with the compiler. Decoupling these systems would require significant refactoring that’s not on my immediate roadmap.
Also, this has the same challenges I mentioned in my earlier reply about supporting HEEX syntax.
Oh, that I understand - people may think the HEEx syntax is supported - makes sense.
Oh sorry, where is a problem here? I was thinking that if you change parent state (which you use to render children) then children would be recreated (with new state), right? For example every time you change options in parent and use them in for syntax then the generated child components using values from said options should be initialised again with new state (options value).
Looks like you explain an update of child component and call template function without init (on update). If so I don’t see why redraw happen if you have outdated state? I would expect that such child is recreated instead. The biggest issue then would be a terminate callback implementation to be able to do some cleanup in some rare cases. Did I miss something? Would that be inefficient?
I see, thanks!
Sorry for all that questions, but you have introduced some “magic” here and there … For example looks like I wrongly assumed that the result of template function is transpiled instead of the whole function by compiler (right)? When I run the skeleton project and enter the page inspector with empty HTML template (just runtime is added) I don’t even see any script tag in the DOM, but there are 2 in the network tab. Everything is very hidden and therefore hard to follow.
When props change, the component is not reinitialized - this is similar to how both LiveView and modern JS frameworks work. Components persist across renders, and only their props are updated. You’re right that the goal is similar to LiveView’s update function, though I prefer a more declarative approach where components can listen for specific prop changes. One key difference is that LiveView’s update doesn’t have access to previous prop values, only the new ones.
No worries at all, I’m here to explain and answer your questions!
I appreciate your inquisitiveness. It’s important to note that I don’t expect users to understand these implementation details. In fact, the goal of Hologram is to let developers focus on shipping features without worrying about the underlying boilerplate they’d otherwise have to write.
If you’re interested in understanding what’s happening with the scripts, you can check out the UI.Runtime module here:
Yeah, I heard about Lynx a couple days ago on Theo’s channel, seems like a cool solution!
