JavaScript Interop in Hologram

I hear you! Really appreciate your extensive feedback! It’s super helpful!

The GitHub repository has been cleaned up!

I understand the importance of having a clear picture of what works and what doesn’t. I’m currently focusing on documentation to help people get started. Soon there will be both a Roadmap docs page and a separate Events docs page. I’ve created a separate forum thread for discussion and announcements about new documentation pages: Hologram Documentation Updates/Feedback

Hologram uses a virtual DOM under the hood, providing a declarative frontend layer that abstracts DOM manipulation. The goal is to eventually transition to more efficient mechanisms similar to SolidJS or Svelte. Could you share specific use cases where you need direct DOM access?

These features are coming in future releases. If you have a specific use case in mind, creating a separate forum thread would be very helpful - this way the whole community can join in, share similar requirements, and maybe even suggest temporary workarounds. Plus, having focused discussions helps us better understand everyone’s needs.

Could you elaborate on your specific use cases that require JSON support?

While there was a working JS sigil implementation previously, I’m cautious about reintroducing it as it might create more challenges than benefits. Proper JavaScript interoperability is relatively straightforward to implement at this stage. If this feature is blocking adoption for you or others, I’m willing to prioritize it. After completing the documentation, I plan to create a dedicated forum thread to understand what features are blocking adoption for users.

I’ve just created a GitHub Issue for this: Add @moduledoc false to modules that don't need HexDocs documentation · Issue #162 · bartblast/hologram · GitHub
Would you like to contribute a pull request?

Before I would take a deeper look at hologram I would like to finish current project that I’m working on. There would be not just example, but a real-world use case. I just have to write documentation and tests, lots of tests …

Well … mention APIs are not that hard to visualise … For example Discourse uses Push notifications, so that’s best real world use case … As above I plan to release also a real-world case for Fullscreen API.

Oh this one is rather low priority, but still it’s definitely part of adoption. In past I saw some hobby sites (just was curious how they work) storing JSON data in data-* attributes and uses it within JavaScript code. For sure they could be rewritten, but just for a hobby project it’s much easier to simply rewrite JavaScript code to Elixir one than rewrite core site logic even if said server/client state would be much better in specific use case.

It’s not rather a part of adoption, but a workaround which would make create demo ports of existing projects much simpler (by copy-paste) rather than waiting for only one feature that’s yet not implemented. As said if there is something relatively simple then it should be added just to see by demo projects how often some features are used and therefore you may prioritise one over others.

Look that I see issue like:
https://github.com/bartblast/hologram/issues/41

and I know that there is no JavaScript workaround support.

So if I would port an existing LiveView application into Hologram I would in fact need to implement more JavaScript logic than less. However if I would have such code:

workaround(s[document.getElementById("?").addEventListener("mousemove", ?)], "some-id", :action_name)

then when feature would be delivered it would be much simpler to update the code as all I would do is to replace said one-liner or even completely remove it in favour of ~H"" markup.

So think:

1. Temporary rewrite logic to JavaScript code + rewrite JavaScript to Hologram when feature would be delivered
2. Write Hologram code and 1LOC in init + remove 1LOC from init when feature would be delivered

Which one would be better for first demo adoption?

Of course in my case if you would say:

Alright, but I can spend one week on it or in exactly same time support all events. What you prefer?

then I would fully agree that such workaround is not important, but this:

1. Would not happen when right now you are focused on documentation (which is a good thing)
2. Even if that would happen it would create just an extra pressure on you to deliver new features asap

That’s why I suggested some kind of a “quick workaround” (if possible) …

Sure!
https://github.com/bartblast/hologram/pull/163

I implemented the ~JS sigil. It will be released in release 0.3.0, probably even today. But please treat it as something temporary – I’m not 100% sure if it will stay.

Example: ~JS"console.log('Hello, world!');"

To return a value, just use the return keyword: ~JS"return 123"

Multiple line statements are also allowed. The sigil just evaluates the given JS code as is.

Brilliant! Any way to reference action?

# TODO: replace sigil code when event would be officially supported:
~JS/someElement.addEentListener("eventName", {hologram_action(:action_name)})/
# …
def action(name, event_params, component) do
  # Action logic here
end

Nope, this will work in simple cases only that don’t affect Hologram state management and DOM abstraction. Example use case: document.documentElement.requestFullscreen(). Such cases will be easily abstracted away in future anyway. Keep in mind that Hologram uses boxed types and there’s quite complex machinery for events, state management and client-server transport underneath, so you can’t just use native JavaScript types.