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 passed. Just like dispatching an event.
push_state() - prima facie seems better and more intentional.
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 rendering would happen. 
Also since the typical naming for 1st argument is server it may be seen as confusing at least at first. The explicit naming says that we are instructing server to push state to the client which make more sense in my opinion. 
100%
Fwiw, I really like this idea and think it’d be worth exploring. Maybe it’s explored in tandem with the planned subscription DSL and local first features.
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.
Yeah maybe… the server state would only be available in commands though so it won’t be exposed everywhere. It will be interesting to see how patterns play out as more things get built
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)
Loving Hologram btw. It’s a thing of beauty.
Yep, automatic/declarative data sync is planned for the next stages - would definitely be more intuitive and reduce boilerplate!
Thanks, noted!
This needs to settle and crystallize properly - it could have consequences for other naming patterns. For example, would we have push_session, push_cookie etc? This could streamline the whole model but also potentially be confusing. But looks promising!
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.