Form doesn't always get cleared after submitting

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
  end

This 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.