When submitting the form, the inputs should clear once I pass an empty changeset, they dont seem to be doing that if I am successful on the first try.
Heres what I mean
heres a snippet of what I am using, is this expected? Am I missing somthing? Thanks in advance guys!
def handle_event("save", %{"volunteer" => volunteer_params}, socket) do
case Volunteers.create_volunteer(volunteer_params) do
{:ok, volunteer} ->
socket =
update(
socket,
:volunteers,
fn volunteers -> [volunteer | volunteers] end
)
changeset = Volunteers.change_volunteer(%Volunteer{})
{:noreply, assign(socket, :form, to_form(changeset))}
{:error, changeset} ->
{:noreply, assign(socket, :form, to_form(changeset))}
end
endThis is a somewhat unintuitive issue. The problem is that the initial value of the form assign is a new Volunteer, which is also the value of the assign after a successful submit. Of course, this makes sense when you want to clear the form to allow another submit with new data. But since the assign never changes to anything else, LiveView does not know that it should rerender things that depend on the assign.
When you attempt an unsuccessful submit, the assign gets updated with the invalid changeset, which fixes the problem. The reason why forms generated with phx.gen work is that they react to phx-change, which updates the assign.
Hopefully that makes sense, Iâve encountered this problem just a few days ago and came to this conclusion.
Yep, thatâs correct. Since LiveView stores its state on the server, you have to continuously update the server state as the form changes.
So in this case the only solution is to create and handle a phx-update?
You mean phx-change? phx-update is not an event, itâs an instruction on how to handle DOM patching. But yes, you must handle phx-change to keep track of your formâs state server-side. You could implement some JS to do it client-side, but this would defeat the purpose of LiveView.
Yes! Sorry I meant phx-change, its just to me its so weird to be forced to handle constant changes in order for the form to clear, but I understand, the diffing that LiveView does, doesnât see a difference so thats why it doesnât re-render it, thanks!
You can also update another assign with an id for the form. Changing the form id makes the form reset. That way you would also add signal to assigns for âthis is now meant to be resetâ.
Oh ya thatâs a good idea! You donât get validations then though it doesnât sounds like OP needs them.
Perfect way to describe it, thanks!
While testing a new feature we ran into this situation which, at the time, we could not explain. Why was the form not updating?! 
It turned out that the particular form input also had phx-debounce, to avoid flooding the server with phx-change events, and if no such events were sent before submit, then the form state from the serverâs perspective never changed, and the form input was not re-rendered and cleared!
Your account of the problem was key to realizing what was going on 
What is actually going on here is that LiveViewâs declarative abstraction is fundamentally leaking its imperative implementation. This is the sort of bug that is not supposed to happen with a declarative programming model.
In e.g. React this is fixed with controlled inputs which always have their state forcibly reset in lock-step with the render (this is declarative programming). Unfortunately this is one of very few things that I think genuinely cannot be fixed in LiveView because it is a consequence of server latency. In almost every case server latency is not a problem, but here it actually is.
This also means that @bartblast should take note, as if he implements controlled inputs correctly this is a case where Hologram will just be strictly and unavoidably better.
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://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.1.14, 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.
© Copyright Elixir Forum | Terms | Privacy & Cookies
