woylie
We are seeing a lot of warning logs like this:
navigate event to "https://someurl" failed because you are redirecting across live_sessions. A full page reload will be performed instead
There are cases where it is difficult to determine whether to use navigate or href.
- A navigation bar that contains links to views in multiple live sessions (e.g. because of different authorization- or CSP-related security contexts).
- A LiveView that receives a
return_toURL as a parameter, which may lead to a different live action in the same view, or a view in the same live session, or a view in a different live session. - A LiveComponent that links to a particular view that may or may not be in the same live session, depending on the view in which the component is rendered.
In either case, using navigate by default in the component will lead to the warning log when navigating to a view in a different live session. Using href by default will cause unnecessary full page reloads and degrade the user experience. Switching between navigate and href dynamically requires the component or view to resolve in which live session the current URL is and which URLs will lead to the same live session.
I can see that this warning might be useful in a development context, but since the switch to a full page reload is done automatically anyway, and dynamically choosing between navigate and href is not always feasible, this log is not very actionable and just increases the log volume.
I’d like to suggest to either remove the log completely, or to add a configuration option to disable it (maybe you’d want it in dev, but not in prod).
Trending in Proposals: Ideas
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 5- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
LostKobrakai
The fallback happens to not break in the users face. It’s not optimal either though. Live navigation happens on the established websocket connection, sending a navigation request to the server, which is rejected there. Then the result is sent back to the client, which then starts with a fresh http request. So you have an additional roundtrip for the fallback to happen.
The optimal case here would be to make your components aware of the difference between plain links to a new live_session and urls they can live navigate to. It would be great if LV would have tools to figure out that distrinction though, to automate this vs. making it implicit knowledge through the developer.
steffend
As @LostKobrakai mentioned, silencing the warning is not a good solution as it requires an extra round-trip for the fallback, though if you really want to do that, you could try
Logger.put_module_level(Phoenix.LiveView.Channel, :error).You can check what live session a route is part of by using
Phoenix.Router.route_info/4, but this requires relying on implementation details:I don’t see a reason why we’d be against adding some official API to do that though
woylie
Thank you. Based on that, I made some helpers to deal with links and pushes/redirects dynamically:
This relies on the specifics of the
route_infodetails, and onsocket.private.live_session_name. I’m also not sure whether it’s correct to read `socket.view` here, or whether it would need to besocket.private.root_view.Which parts of this do you think could be added to LiveView? I’d be happy to open a PR once we agree on the API.
woylie
If you patch to the current route,
handle_paramsis always called, even if there are no parameters. If you useresolve_link_attrsfrom the example above in your main navigation, you’ll get anUndefinedFunctionErrorwhenever some clicks on the navigation link to the current view if that view does not have ahandle_paramsfunction. Unless you want to add dummyhandle_paramsfunctions to all LiveView modules, you may want to mappatchtonavigate(or rewrite it to not reuse thenavigation_typefunction):steffend
LiveView 1.2.10 adds
navigation_type/2!