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.

Funny, this client/server interface is exactly the one that OTP enforces via GenServers

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 then the client should still be responsible for performing state mutations. You can then checkpoint the state back to the server at regular intervals. In this case you want the endpoint on the server to be as general as possible. So I don’t think a specialized push_state() is necessary as it should be trivial to create a one-off :update_state action and shovel all of your state through it anyway. What really matters is the policy for what can be accepted, which is not the framework’s concern (unless you want to design a framework for that).

Finally, if the server owns the state and the client only issues restricted updates then you want to stick to the “action” model you have in that case anyway. This is how e.g. LiveView works now, and is a reasonable model for some problems.

The cool thing about Hologram is that it can be all three of these at once. But I don’t think any of them necessitate the API proposed (push_state()). Ideally you should encourage developers to define a general policy for what state to accept based on their application’s needs.

Also, providing tools to accept state on the server with no validation sounds like a security footgun waiting to happen.

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 pattern where a command enqueues a client action and that action calls put_state on the client. The proposal doesn’t change the trust boundary or validation story, it only removes boilerplate for the “command → action → put_state” sequence.

I also think this is what @absowoot meant initially - @absowoot, does this match your intention?

Another example of the same pattern:

1. User fills a form
2. A command runs on the server to create a user in the database
3. The command triggers an action that updates the client-side component state with the created record

Today:

def command(:create_user, %{data: data}, server) do
  {:ok, user} = MyApp.Users.create_user(data)
  put_action(server, :user_created, user: user)
end

def action(:user_created, %{user: user}, component) do
  put_state(component, :user, user)
end

Proposed sugar:

def command(:create_user, %{data: data}, server) do
  {:ok, user} = MyApp.Users.create_user(data)
  push_state(server, user: user) # sugar for enqueuing a client-side operation that calls put_state/3
end

Anyway, this is just an idea - I’d still like to let more usage patterns emerge (and land resiliency/error-handling primitives) before adding sugar so we don’t blur the “actions on client, commands on server” mental model.

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.

Another common one is file uploading. An isomorphic Req could be cool.