mitkins
I’m currently re-writing my form to create/edit Log entries with Phoenix Live View. I have an unorthodox UI - it has 2 submit buttons. 1 for “Work” and one for “Break” - offering the user the choice, but allowing the user to submit the form at the same time. So at the time of submitting the form - I need to know which button the user pressed.
In a traditional POST I use the name of the button - in my template I have the following:
<%= submit "Work", name: "work" %>
<%= submit "Break", name: "break" %>
If the user clicks a button, either work or break would exist in the list of params.
In a Live View, I don’t have this technique at my disposal. handle_event does not include the name of the submit button that was pressed.
I tried adding a phx-value-work attribute (which seems like an awesome way to solve this), but that only works with phx-click.
Does anybody have any suggestions?
Trending in Questions
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixirconf-us
- #ai
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming











Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
mitkins
I’m thinking at this stage that I may be better off creating some client-side javascript to set a hidden field before the form is POSTed. I might have a look at the JS interop mechanism and see what’s possible there…
mindok
Does this thread help? It sounds like a similar situation.
mitkins
It does. Looks like I do need to set a hidden field using javascript before
phx-submitevent is fired.Though, I think I might start by adding a
phx-clickfirst:In my code I have something similar to this;
I’m assuming this results in 2 round trips (
phx-clickfollowed byphx-submit), but the code is easier to read. I might do this for now until I’ve fleshed out my formsnewcomer
If we aren’t passing more information to
handle_eventand it helps your case, I think we should! It is so common to include two buttons in a form so something like this should be simple to handle.Would you mind opening an issue in the LiveView repo so we can discuss?
mitkins
No problem!
https://github.com/phoenixframework/phoenix_live_view/issues/511
technicalcapt
In case of anyone come across this topic. Here is my solution for this particular issue.
Form
Js logic with jquery
Use a controller to handle ajax request.
And finally
handle_info/2marcofiset
Isn’t this kind of convoluted?
This issue can be solved purely on the client side with javascript, which you’re already doing. Instead of initiating an ajax call, why not simply set a hidden input on the form?
APB9785
My first intuition here would be to use
phx-clickinstead, and pull the form data out of the assigns manually (assuming you’re using live validation).ouven
I tried this but the validation didn’t work, because, if the form was not submitted, the class “phx-no-feedback” is set to the fields, that had no focus yet. So the changeset errors are not shown.
nihil2501
Here is a formulation that relies on
SubmitEvent.submitterdocsuseCaptureoption ofaddEventListenerdocs (maybe ensuring the behavior occurs before the actual submit occurs?)It worked locally for me in a really simple example, but I’m both new to Elixir and Phoenix and not intimately familiar with browser behavior, so it might be inaccurate.