Yeah, this is already solved in Hologram since v0.6.0 
It’s called “synchronized inputs” and it works in a similar lock-step fashion - the component state is always the single source of truth, and input values are kept in sync declaratively through unidirectional data flow.
Check out the docs here: https://hologram.page/docs/forms
Forms: 
solved!
You’re always spot on with your insights @garrison, thanks for chiming in!
I would like to offer a hint for others (and myself in the future) with a possible path forward. First, summarizing the issue:
id, phx-change, phx-submit and phx-debounce. The latter makes it more likely that a submit event may reach the server before any change event, but I believe is not fundamental to trigger the issue.to_form(%{})."hello".to_form(%{}).hello remains visible 
So in previous messages in this thread we talked about the “no change from the server’s perspective”. There’s a little bit more into play here, for which I refer to the LiveView documentation:
The JavaScript client is always the source of truth for current input values. For any given input with focus, LiveView will never overwrite the input’s current value, even if it deviates from the server’s rendered updates.
So even if in step 4 above we’d assign to_form(%{content: "some other value"}), LiveView would still not update the visible input value (assuming it would be focused when submitting the form).
After evaluating a few options, I decided to go with a “pessimistic UI update” in my particular case. It means I want the client to clear the input only after the event is handled in the server and there were no validation errors, etc.
Eventually, the change is small but combines different concepts, so I decided to share.
push_event/3 to send (JS) events from server to client, only in the success path.JS.set_attribute/3 command that works on HTML attributes).defmodule MyApp.MyLive
def render(assigns) do
~H"""
<.form
for={@form}
id="my-form"
phx-change="validate"
phx-submit="send"
phx-debounce
class="phx-submit-loading:opacity-50"
>
...
</.form>
"""
end
# ...
def handle_event("send", %{"message" => message}, socket) do
socket =
case send(message) do
{:ok, message} ->
socket
|> assign(form: to_form(%{}, as: :message))
|> clear_input()
{:error, changeset} ->
socket
|> assign(form: to_form(changeset, action: :submit))
end
{:noreply, socket}
end
defp clear_input(socket) do
socket
|> push_event("myapp:setproperty", %{
"selector" => "##{socket.assigns.form[:content].id}",
"property" => "value",
"value" => ""
})
end
end
// app.js
// Similar to `JS.set_attribute/3` but sets a DOM property instead of an HTML
// attribute. The distinction is important for certain properties like `value`
// on input elements, which do not reflect changes made to the attribute.
// https://forum.elixirforum.com/t/using-liveview-js-to-manipulate-input-values/46371/2?u=rhcarvalho
// https://hexdocs.pm/phoenix_live_view/syncing-changes.html#the-problem-in-a-nutshell
// https://hexdocs.pm/phoenix_live_view/form-bindings.html#javascript-client-specifics
window.addEventListener("phx:myapp:setproperty", event => {
const target = document.querySelector(event.detail.selector);
target[event.detail.property] = event.detail.value;
})
“Optimistic” UI updates with JS commands, like
phx-submit={
JS.push("send")
|> JS.dispatch(
"setproperty",
to: "#field-id",
detail: %{property: "value", value: ""}
)
}
This also works, instantly clears the text input (assuming an event handler for setproperty), and correctly recovers the submitted value in case of a validation error.
Client hooks with phx-hook, possibly using the new ColocatedHook in LV 1.1.
Listening for the phx:page-loading-stop event as part of the form submit flow.
Custom submit handler.
Quoting Form bindings — Phoenix LiveView v1.2.5, emphasis mine:
The JavaScript client is always the source of truth for current input values. For any given input with focus, LiveView will never overwrite the input’s current value, even if it deviates from the server’s rendered updates. This works well for updates where major side effects are not expected, such as form validation errors, or additive UX around the user’s input values as they fill out a form.
I continued reading the page looking for “conversely, what do I do when major side effects ARE expected?” – not found
If anyone wants to continue the discussion in this direction we might be able to fill in that gap in the docs together!
Thanks! 
Concurrent changes to a shared input value between the client and the server under latency are not trivially handled. You run into all the problems of distributed computing there. Even client side libraries in the past got this stuff wrong - and they didn‘t have a network on the path. LV does.