I’m trying to push_redirect from one LiveView to another. It’s working BUT… there’s a seconds long delay until the browser refeshes and renders the new LiveView. What am I missing?
def handle_params(%{"query" => query}, _url, socket) do
Logger.info "handling query"
{:noreply, socket |> assign(query: query) |> fetch()}
end
The logging looks like this…
12:07:54.013: [info] pushing query
12:07:54.022: [info] handling query. #<- render not triggered
12:08:00.565: [info] GET /results/duk # <- render refreshes and new LiveView is displayed and data added 6 seconds later?
12:08:00.566: [info] handling query
When I go directly to the ResultsView in the browser it renders immediately, it’s only on redirect that it has this delay. I’m sure I’m missing something in terms of lifecycle/routing, but not really sure what! Many thanks
You can only live navigate between LiveView A and LiveView B if they are in the same live_session defined in your router. We detect the bad live navigation and instruct the client to do a full redirect instead, but you’ll pay an extra round trip for it. So in your case it’s whatever your RTT is * 3 to get to a new page. One for the event that does push_navigate , one for the attempt at the new LV mount which fails because it’s in a different live session, and one for the regular page redirect (the GET in your logs). Since your push_redirect (now renamed to push_navigate) results in a GET request in the logs, this is definitely what is happening. Hope that helps!
Yes. We’ll need to see the full code and logs to say more. Are you seeing in logs on the client with liveSocket.enableDebug() in the js console? The client will also force refresh the page as a failsafe if it detects it’s in an unrecoverable scenario such as repeated LiveView mount failures after connecting to the websocket. You should see stacktrace errors in your server logs in such cases.
What happens if an app doesn’t use live_session/3 at all? Are all views treating as if they were all in the same live_session, or all as seperate ones (meaning extra RTTs)?
Glad someone else has been able to recreate this! I’m not seeing any liveSocket debug in the console and only the message destroyed: the child has been removed from the parent - undefined
Is this happening only in localhost? I’ve posted to this forum before that I had really odd delays in LiveView’s initial websocket connection when I was using localhost under Chrome. I was using Windows 10 and if I used 127.0.0.1 instead of localhost that delay wasn’t there.
The above could also be exasperated by a slow setup/mount phase of the target liveview (like a big data load or some other blocker in mount). in which case it would be the roundtrip penalty described + that slow startup/setup penalty.