I’m very interested in all of that, but particularly what happens inside the register_hook component. Care to share?
frankdugan3
0
Lucassifoni
I’m a bit hesitant because it’s going quite against the flow… but hey, why not.
Here’s a simplified version :
JS side, there is a function allowing to register a dynamic hook, and a record holding them.
Sorry if there are syntax errors, I do not have the project on hand.
declare global {
interface Window {
__liveutils: {
registerHook: (name: string, cb: () => void) => void,
dynamicHooks: Record<string, Hook>
}
}
}
The register-hook component calls this registerHook function by just rendering the script. Note that inline scripts need special care to work with CSP headers : Content-Security-Policy : directive script-src - HTTP | MDN
<script phx-update="ignore" id={@name}>
__liveutils.registerHook('{ @name }', (<%= @bind %>) => <%="{"%>
<%= Phoenix.HTML.raw(assigns[:script] || "") %>
<%="}"%>);
</script>
The bundled app.js needs to have a hook dedicated to handle those runtime-registered hooks :
let liveSocket = new LiveSocket("/live", Socket, {
params: ...,
hooks: {
dynamic_hook: {
mounted() {
const hook = this.el.getAttribute("data-hook");
if (window.__liveutils.dynamicHooks[hook]) {
window.__liveutils.dynamicHooks[hook].mounted(this, this.el);
}
},
... rest of lifecycle
}
}
};
And a basic registerHook function would be as simple as this :
registerHook = function (key, fn) {
window.__liveuitls.dynamicHooks[key] = {mounted: fn};
};
Then, the LiveSocket object is only aware of a dynamic_hook hook that could be used like that :
<div phx-hook="dynamic_hook" data-hook="act_on_coordinates" data-foo="bar">...</div>
So, there’s somewhere a map of callbacks, a function to register them, and they are looked up when an element with phx-hook=“dynamic_hook” is rendered.
But I’m not advocating for that too much. My use case is very small, one-purpose independent liveviews that might or might not be loaded into a main app. The app itself has a “real” frontend with a build system for libraries and compile-time liveviews..
2
frankdugan3
I just read your recent article, loved it! Did you ever implement syntax highlighting for sigils? I’m doing some experiments with component tooling around CSS and JS sigils, syntax highlighting would be icing on the cake.
1
LostKobrakai
frankdugan3
Of course, but it was mentioned in the post it was being worked on. I have looked into adding generic support for various languages in treesitter, which is non-trivial (for me) to jump in and implement, especially since I want highlighting for the embedded language and EEx templating. So, I was hoping for an example to draw from for JS in particular. 
0
Lucassifoni
Hello Frank,
I did not yet get to it but it’s on my very near todolist because It looks like I’m not done with code-in-code approaches.
I’ll post an update but since the way is to scaffold an editor plugin, I’ll only be able to provide samples for Code and Zed.
1
Lucassifoni
Whew ! That was quite a rabbit hole .
I need to clean up the VSCode extension project and I’ll upload it to github.
I used an LLM and VSCode docs and bits of syntax highlighter plugins to guide me.
Highlighting JS is a bit different (in an easier way) than the official HEEX support because HEEX isn’t quite HTML. In short, you “just” have to tell tree-sitter to consider the inside of ~SIGIL"“” / “”" as another language that is already supported.
So highlighting CSS (or even Zigler NIFs!) shouldn’t be too hard to add to that kind of plugin.
I’ll provide the vscode/zed extensions code but will not package them, because I’m not in a position to take maintenance of a “public” plug-in today.
1
frankdugan3
Oh wow, this was waaaay easier than I thought with Neovim!
; ~/.config/nvim/queries/elixir/injections.scm
;; extends
(sigil
(sigil_name) @_sigil_name
(quoted_content) @injection.content
(#any-of? @_sigil_name "JS")
(#set! injection.language "javascript"))
Thanks for pointing me in the right direction.
1
Lucassifoni
If someone has a similar need someday, here’s the VSCode extension POC repository :
https://github.com/alzo-archi/vscode-sigil-js-highlighting-sample
Zed looks a lot leaner on ceremony but Neovim seems to take the crown here ! 
I’ve also linked to this discussion in my blog post. Thanks for giving me the necessary push !
1
Lucassifoni
I’m bumping this as I see that Colocated hooks are in the works : Colocated Hooks by SteffenDE · Pull Request #3705 · phoenixframework/phoenix_live_view · GitHub
The fact that there will be a bundling/runtime distinction seems perfect to me and covers my use cases well. This would enable loading Liveview apps at runtime without hacks.
Huge thanks to SteffenD and the Phoenix team, this will be a real enabler.
4