Hey folks,
I’ve started publishing Build in Public posts about Hologram, roughly 1-2 times a week. They cover the design thinking behind framework features as they happen: pivots, trade-offs, the messy middle of API design before things ship, and so on.
First one is up now about the realtime layer I’ve been working on the last few weeks.
If that’s the kind of thing you want to follow:
cool 
Apologies if annoying, but how far down the road is importing and calling Elixir functions in hologram from JS?
No worries, good thing to ask!
Action dispatch from JS already works today via Hologram.dispatchAction("name", "target", params) - that’s the supported path. See the “Dispatching Actions from JavaScript” section in the docs: JavaScript Interop.
Calling arbitrary Elixir functions from hand-written JS (outside the action-handler model) isn’t planned though. Hologram doesn’t just transpile - it’s a full compiler. Among other things, it analyses the call graph at compile time and ships only the Elixir code each page actually needs (which is why Hologram bundles stay so small). A JS call site referencing an arbitrary Elixir function is opaque to that analysis, so the function (or its transitive deps) could get tree-shaken out of the bundle. Action dispatch sidesteps this because actions are first-class compile-time entry points the compiler already traces.
The reverse direction - Elixir → JS - is mature today via the Hologram.JS module: js_import, JS.call, JS.get, JS.new, the ~JS sigil, etc. (Same docs page covers both directions.)
Thank you!
So, just to confirm before diving into it: I can now reuse full fledged Elixir modules otherwise used server-side and invoke their functions from my web components by merely having a hologram wrapper for them ( Hologram.dispatchAction("name", "target", params)?
Correct!
Yeah, I’ve just checked it with my LLM. Thanks, man! This looks great!
© Copyright Elixir Forum | Terms | Privacy & Cookies
