How can you define different things to render in the first and on the second rendering? I though we could only use one template (assuming you have a live route) and as such you would need to render the same content.
Could you point some example/info, please?
PJextra
0
PJextra
Missed this link in the thread…it’s explained here: Shortcomings in LiveView - are there any I should look out for? - #10 by josevalim
0
sodapopcan
I have a page that loads content based on the first URL parameter and uses live_patch in its navigational event handlers—If there is no parameter, then it provides a default.
Knowing that handle_params always gets called and I don’t care about checking any mount-type behaviour (like socket_connected?) should this golden rule still apply? I found I was able to simplify my code (and still have it work with JS disabled) with the following:
@default_assigns [
entity: DB.find("default_entity"),
# ... more keyword list entries
]
@impl true
def handle_params(%{"term" => term}, _session, socket), do:
{:noreply, assign(socket, @default_assigns |> Keyword.replace!(:entity, DB.find(term)))}
def handle_params(_params, _session, socket), do:
{:noreply, assign(socket, @assigns)}
@impl true
def handle_event("submit", %{"term" => entity}, socket), do:
{:noreply, push_patch(socket, to: "/#{entity}", replace: true)}
The site in question is an art project and this works so there is nothing at stake here, I’m just trying to grok best practices.
Note: DB is just an example and not something that makes a database call (even Ecto isn’t involved). I’m pretty sure I can understand why setting attribute values based on a db lookup is probably a bad idea… but is it??
Ok, thanks!
0
josevalim
Creator of Elixir
I would say your snippet is correct. Since that particular parameter/assign can change, it should be loaded in mount instead of handle_params.
0
sodapopcan
Thank you for the response!
Did you mean my snippet is incorrect?
My thing is that I want to handle loading / and /:entity, so to handle it in mount, I’d need my two implementations of mount to handle them (def mount(%{"entity" => entity}, ...) and def mount(_params, ...)) and then that exact same handling logic would be repeated in equivalent handle_params implementations. Since handle_params gets calls after mount anyway, why should I bother assigning assigns in mount in this case?
Thanks again!
0
josevalim
Creator of Elixir
the params that can change are loaded on handle_params.
sodapopcan
Thank you so much for your response. I realize I’m being somewhat pedantic though I’m quite new to functional programming (under a year) and want to ensure I understand the paradigms and avoid shoehorning my OO and Rails knowledge into Elixir and Phoenix.
0
tfwright
Hoping someone can check my work on this issue, since I haven’t had the opportunity to work with LV in production much:
I ran into an issue where I had some data that needed to be loaded in different ways depending on the content of the params, and if it was not loaded correctly, it would fail. I had moved all the logic into handle_params already, but because on initial load the query params were not passed, and since the absence of the query param is a valid option in some cases, I couldn’t rely on pattern matching to always skip the logic in question as I have in other cases in the past. As a result certain views would break because it would try to execute the code as if the param were absent even when it was actually present in the uri.
def handle_params(params = %{"path_param" => needs_y, "x" => y}, _, socket) do
socket = assign(socket, :data, load_func(needs_y, y))
{:noreply, socket}
end
def handle_params(params = %{"path_param" => no_y_needed}, _, socket) do
socket = assign(socket, :data, load_func(no_y_needed) # <- this fails on initial render before "x" is passed
{:noreply, socket}
end
One option I considered was actually parsing the URI directly to determine whether param was present or not and wait until it was passed if so:
def handle_params(params = %{"path_param" => maybe_needs_y}, uri, socket) do
if String.contains?(uri, "x") do
if x = params["x"], do: assign(socket, :data, load_func(maybe_needs_y, x), else: {:noreply, socket} #wait
else
assign(socket, :data, load_func(maybe_needs_y)
end
end
…but that seemed awkward and potentially fragile.
So instead what I did was introduce a loading param that I set to the value of connected/? in the mount function.
def mount(_, _, socket) do
# other stuff
socket = assign(socket, :loading, !connected?(socket))
{:ok, socket}
end
def handle_params(_, _, %{loading: true}), do: {:noreply, socket} # wait
def handle_params(params, _, socket) do
# query params present, exec loading data
end
So far this seems to be working but my sense is that this may not be what the connected? check is intended to be used for.
0