Hologram is amazing and I love playing with Elixir in Front-End as well instead of using some JavaScript/TypeScript libraries/frameworks. Just another topic, but how can I interact with some external APIs on the client side (not from the database)? Can I use something like fetch API/Axios or even s…

Is there a way to fetch data from an API (on load) without render blocking? If I add :timer.sleep(5000) to my request, the page does not load until the request is complete. I attempted to fetch the response with Task.async but I can’t seem to get the command to execute on init, whether in a page or…

[image] jam: Another common one is file uploading. An isomorphic Req could be cool. Yeah, file uploading with pre-signed URLs is another great use case! Besides that, an isomorphic HTTP client would become essential once we start implementing Local-First features.

[image] absowoot: Is there a way to fetch data from an API (on load) without render blocking? If I add :timer.sleep(5000) to my request, the page does not load until the request is complete. I attempted to fetch the response with Task.async but I can’t seem to get the command to execute on init,…

Good to know, thanks! I’m seeing a repeating pattern where an action needs to be created to accept changes from a command. def command(:fetch_todos_async, _params, server) do ... put_action(server, :add_todo, todo: todo) end def action(:add_todo, %{todo: todo}, component) do put_state(compon…

Yeah, I’ve noticed this pattern emerging too! You’re right that it feels repetitive having to create an action just to accept changes from a command. I’m intentionally holding back on implementing sugar syntax or DSL features right now - I want to wait until more usage patterns emerge and solidify.…

Funny, this client/server interface is exactly the one that OTP enforces via GenServers :slight_smile: My opinion: if you want to build an interactive app, you want the state on the client. This is the key differentiator for Hologram. If you want to ship state owned by the client to the server the…

Just to clarify the idea that was floated: push_state would be called inside a server-side command and would only push a state update down to the client-side component. No state would be accepted from the client to the server through this API. Concretely, it would just be sugar for the existing pat…

I see, looks like I had it the wrong way around. I imagined Hologram would synchronize state like this back automatically. Maybe an API focused on sync or subscription rather than explicit pushes would be more intuitive? Of course you have to be careful not to accidentally build a database …

[image] bartblast: push_state(server, user: user) push_state() seems like a good idea. It clearly states the intent of pushing state from the server to the client. For me the put_action in the command seems like issuing instructions to the client to change the state with the data being pass…

[image] bartblast: push_state(server, user: user) How about push_client_state instead? Recently I found that I really like the explicit naming even if it’s longer and declaring that some data would be set on client side more clearly shows (without a need to read documentation) where the rende…

Calling external APIs from Hologram

Questions & Help Questions

bartblast August 15, 2025, 11:05am 19

Yep, automatic/declarative data sync is planned for the next stages - would definitely be more intuitive and reduce boilerplate!