Calling external APIs from Hologram

[bartblast]

@dblack

Will there be the possibility of storing state on the server as well? I don’t mean session or cookie state, but state that is used during the lifecycle of the page or component.

For example, with something like AshPhoenix.Form, you would store a form struct in the live view assigns, and reuse it on each form validation and submit.

Hmmm… you’re thinking about server-side state for components, which is a natural question coming from LiveView! Hologram is designed to keep component state on the client side - right where the user interactions happen. This approach actually makes a lot of sense for most use cases.

For your form example, I think storing the form data on the client would actually be better than server-side state. Here’s why: the user is filling out the form on the client, and all the form processing code gets transpiled to JavaScript and runs right there in the browser too. This keeps everything close together and responsive.

Could you share a specific use case where you think server-side component state would be beneficial? I’m curious to understand the scenario you have in mind, as the current client-side approach works really well for most interactive patterns.

[bartblast]

@Pal

I am nothing and nobody to post anything here, so forgive my intrusion but is it feasible, in the interest of aiming for a truly isomorphic approach, to keep action/command separation invisible and make code run through three modules in a kind of kernel: Action | Dispatch | Response. Then there’s no ‘client or server?’ branching in app code because the transport swaps out under the hood so to speak.
ie contract in Behaviours/Protocol, the kernel + two transports in one ‘interface’. It’s probably not very Elixir, sorry.

(I learnt this kind of pattern through John Elm Labs & a bit of coding gnome - kudos to them)

Interesting! Could you give some link to see it in action? I couldn’t find it anywhere.

@Pal

Loving Hologram btw. It’s a thing of beauty.

This just made my day Thank you so much!

[Eiji]

I would say that naming of pushing something should not change only if source is same as target, so changing something server-side on server or changing something client-side on client.

Alternatively we could use separate naming patterns like set and push, so we say that we are setting things when source is as same as target and pushing things to a different target i.e. client -> server or server -> client. This way we would have set_session and push_state.