axelson
I’m trying to reset my LiveView form programmatically (on submit) but I’m having lots of trouble getting the form to reset programmatically in a way where my LiveView can trigger the reset.
My form is driven by an Ecto embedded schema that is specific to this form (since my persistence is not via Ecto itself but instead a remote api that is mediated by a separate js script). I am using core components which I would expect to support this.
Things I’ve tried/links I’ve tried:
- How do I reset form input on submit?
- https://stackoverflow.com/questions/70632646/phoenix-liveview-form-submit-clear-reset-input-value
- https://stackoverflow.com/questions/79022720/reset-form-after-submission-elixir-liveview
- Changing core_components
input/1fromassign_new(:value, fn -> field.value end)toassign(:value, field.value) - “Reset Form” section of the docs Form bindings — Phoenix LiveView v0.20.17
- This only mentions resetting forms by providing an HTML form, nothing about resetting forms via LiveView itself (or via js)
No matter what I try I can’t get the form to change based on my liveview assigns unless I manually set value={@something}. But none of the examples I see include setting value and I don’t see a straightforward way to get the value of a field. I guess there’s Phoenix.HTML.Form.input_value but it feels wrong to use that directly in a form (it would make sense in a re-usable component but not in a form).
I’d like to avoid needing to trigger the reset from javascript if possible because this seems to me like something that should be possible directly from LiveView (and from other answers here it appears to be).
I feel like I’m missing something simple, hence the forum post.
My LiveView looks like:
defmodule MyForm do
use Ecto.Schema
@primary_key false
embedded_schema do
field :note, :string
field :amount, :string
end
end
def reset_form(socket) do
assign(socket,
form:
%MyForm{}
|> Ecto.Changeset.change()
|> Phoenix.Component.to_form()
)
end
def render(assigns) do
~H"""
<div class="w-full max-w-md mx-auto p-4">
<div className="relative">
<.form for={@form} phx-change="validate" phx-submit="submit">
<.input
id="note-input"
field={@form[:note]}
class="w-full pl-10 pr-4 py-2 border border-gray-300 rounded-lg focus:ring-2 focus:ring-blue-500 focus:border-blue-500 bg-white shadow-sm transition-colors duration-200"
type="text"
placeholder="Note"
/>
<.input
id="amount-input"
field={@form[:amount]}
type="text"
inputmode="decimal"
placeholder="amount"
/>
<.button>Send!</.button>
<button type="reset" name="reset">Reset</button>
</.form>
</div>
</div>
"""
end
def handle_event("validate", params, socket) do
socket = reset_form(socket)
{:noreply, socket}
end
def handle_event("submit", params, socket) do
socket = reset_form(socket)
{:noreply, socket}
end
Note: the reset button does reset the form but I don’t think I can directly trigger the reset button via LiveView
Here’s a repo with a reproduction:
https://github.com/axelson/phoenix_live_view_reset_form_repro
Steps to reproduce
- Run
mix.setup - Run
iex -S mix phx.server - Visit http://localhost:4000
- Fill out the form
- Press submit
- The form is not cleared but I would expect it to be cleared because I call
reset_formwhich assigns a fresh@formassign
Trending in Questions
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #blog-post
- #phoenix_html
- #iex
- #graphql
- #ai
- #genstage
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex










First 9 of 9 Posts
LostKobrakai
The simplest way to reset a form is updating its
idattribue. That makes LV consider the node to be a replacement for the old one, resetting any state it might still hold onto.axelson
Hmm, that sounds like it should work, but passing
<.form id={@some_id} ...>(and changing its value) doesn’t have any effect on resetting in a quick test. And I don’t see an ID attr accepted in the docs (although maybe ID is considered a global?): Phoenix.Component — Phoenix LiveView v1.0.0-rc.7Here’s what I tried: Try to reset by changing the id by axelson · Pull Request #1 · axelson/phoenix_live_view_reset_form_repro · GitHub
LostKobrakai
I’m doing exactly that here: kobrakai_elixir/lib/kobrakai_web/live/one_to_many_form.ex at main · LostKobrakai/kobrakai_elixir · GitHub, live at One-to-Many LiveView Form | Benjamin Milde
Haven’t updated LV on this one in a few weeks though.
slouchpie
I do not understand your code. In particular, the
handle_event("validate"part makes no sense to me. What is supposed to happen whenphx-changeis triggered?axelson
Yeah the validate event is not at all something that I would actually use because if it worked properly it would reset the form for all the fields that don’t currently have focus. I’ve written it that way in an attempt to reset the form from LiveView.
steffend
If it’s fine to lose other state,
push_navigateing to the same LiveView is often the most simple way to reset forms.axelson
I see that your form has an
idset and it gets updated every time the form is saved. But in my testing the form is not reset in any fashion after the form is saved:Also if I remove the
idfrom the form completely I don’t notice any changes in behavior.axelson
Using
push_navigateto the same LiveView does work, but is there a way to keep my LiveView not knowing where it is mounted?push_navigaterequires you to pass a path to navigate to and currently my LiveView doesn’t know what path it is on (and for a general reset mechanism I wouldn’t want to enforce knowledge about the path). And doing some quick research it doesn’t seem like LiveView makes the current path available to you generally (although you could store that yourself usingc:handle_params/3).LostKobrakai
The only observable behaviour in the form would be deleting an existing row, because the rows are only tagged for deletion within the livecycle of the form/changeset modeling it.