Oh!
I am trying to do exactly this in the future. But couldn’t you have a LiveView template conditionally render another template inside of it? Haven’t tried this yet but will be crossing this bridge soon.
Owens
OvermindDL1
You can conditionally render all you want as it is right now, but the backend functionality has to support everything you potentially want to do, whether actually using it or not, instead of allowing the system itself to manage it. It’s the main feature I’m waiting for liveview as my server design is integrally tied into the drab subcommander style of piecing things together (which I adore as it works really really well!), plus some other features like more fine-grained control of the page that liveview does not allow for yet without some really convoluted work-arounds that don’t fit even remotely easy, but is trivial in drab. ^.^;
2
ryan-senn
This is a massive bummer. I have a really, really big form with one country select in the middle. Based on the selected country, I want to display something differently. I do absolutely NOT want a phx-change on my form (massive amount of data on the wire (textareas with tens of thousands of words)), I just want a phx-submit. How do I detect the changes to just my country select? Doesn’t seem like I can nest forms either.
5
gutschilla
Hi @ryan-senn,
first of all, welcome to the Elixir Forum! I do have the same issue – I want finer-grained control. Right now, I abuse the phx-keyup in conjunction with phx-focus and phx-value to achive the desired function:
phx-focus will send the currently focused input element identified by the value in phx-value /some index). The value of the input field itself will be send on each keyup event.
See phoenix-liveview-todo-app/lib/live_demo_web/views/page_view.ex at master · gutschilla/phoenix-liveview-todo-app · GitHub for an example.
0
ryan-senn
Thanks for your answer. I’ve read about a few other people (ab)using keyups to suit their needs.
The input that I want to listen to is a select and not a text input however (I assume no keyup?). I haven’t actually tried to dig deeper just yet, the app we’re developing won’t be released for another 2 months, making it a not so urgent situation.
I mainly wanted to share my use case to demonstrate that input level changes can be beneficial in some circumstances. I just intuitively assumed that it was an option, so it was quite a surprise to find out that it isn’t. Maybe because of previous experience with elm/react etc.
Thanks again for your example, it’s an interesting trick. I’m sure it will help out quite a few people searching how to do this!
2
tomekowal
Sorry to resurect old topic but I have question about how the combination of keyup, focus and value work.
I still don’t understand which event does what?
I’ve learned that phx-change cannot overwrite the value in a focused text input. Is the phx-focus somehow mitigating that?
0
darkmarmot
I think this is my biggest current wish for LiveView as well in terms of supporting composable forms.
With the awesome new live_component setup, it has become much easier to compose LiveViews. But, this feels hobbled by the current JS interop that requires handling forms as a single unit (without going all JS hooky). Some kind of override allowing one to manipulate input values outside of phx_submit would be especially helpful for me.
1
tme_317
Agree… I love the new live_components. I am using them extensively!
You can manipulate input values of any non-focused fields without using hooks by using phx-change. By default your handle_event will fire on every keystroke but you can use phx-debounce to have it fire after x ms or onBlur. In your handler you can feed the params into your form’s changeset function (which has all the validations), put_change any manipulations to non-focused fields, then generate a new form struct running form_for on the changeset. Then you just put the new form struct into your assigns and you should be good to go!
Mutating focused fields (like masked inputs and the like) I’m pretty sure you do need to use hooks probably due to latency and race conditions. You can do it with vanilla JS as shown in the docs but I like to use phoenix_live_react.
3
sandeshsoni
Hi,
what solution did you come up with?
I am on the same question… using select so cannot use keyup event.
better scenario…
how to choose state then choose city then region.
select box to choose state then show options for list of available cities.
list of states and list of cities will not be a part of changeset. but selected_city_id and selected_region_id will be.
# My LiveComponent
def render(assigns) do
~L"""
<div class="input-box">
<%= select(@opts.form_handle, :select_id, @opts.city_pairs, phx_window_keydown: "city_selected") %>
<span class="error-msg">
<%#= error_tag @opts.form_handle, @opts.select_id %>
</span>
</div>
"""
end
def handle_event(msg, params, socket) do
IO.puts "city selected .........................."
{:noreply, socket}
end
def handle_event("city_selected", %{"landmark" => landmark_params}, socket) do
IO.puts "city selected .........................."
# IO.puts inspect(params)
{:noreply, socket}
end
# it straight goes to form event...
0
chrismccord
Creator of Phoenix
the params will contain a "_target" which is the name of the form field which triggered the change, so you can use that to handle the city => state => etc flow
2