-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LiveView usage question #71
Comments
I'm afraid "wreak havoc" is not an actionable error report. What happens? What exception do you get? There's no special handling needed for live select inputs, unless you're dealing with something that needs to be JSON encoded/decoded |
I apologize for the incomplete error report. That is completely on me. The main issue I was having when I said "wreak havoc" was that the live select was displaying the "value" instead of the "label" when updating
This makes me think its something to do with my setup. Today I will write up a complete error report / single file example and comment here regardless of I get it working as expected. Thank you for getting back to me so fast. |
This was an error on my end. My apologies. |
I have a question about usage in a LiveView.
Lets say I have a form with two inputs one text input and one live_select:
I would initialize the form on mount and then we have two different handle_event handlers
I believe the current best practices for LiveView forms is to to take the
params
passed into the "change" event and pass them toPhoenix.Component.to_form
and reassign the@form
assign. This seems to wreck havoc on live_selects. (or I'm doing something else wrong)I think sending an update with
send_update
and updating the@form
assigns causes a race condition and ends up displaying the "value" instead of the "label" for selected options.I'm not really sure how I'm supposed to handle this scenario, any guidance?
The text was updated successfully, but these errors were encountered: