woylie

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_to URL 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).

Showing Posts 1 to 5

LostKobrakai

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

steffend

Phoenix Core Team

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:

def live_session(path, host) do
  case Phoenix.Router.route_info(MyAppWeb.Router, "GET", path, host) do
    %{plug: Phoenix.LiveView.Plug, phoenix_live_view: lv} ->
      {view, _action, _opts, live_session} = lv
      {:ok, view, live_session.name}

    %{} = not_a_live_view ->
      {:error, :not_a_live_view}

    :error ->
      {:error, :not_found}
  end
end

I don’t see a reason why we’d be against adding some official API to do that though :slight_smile:

woylie

woylie OP

Thank you. Based on that, I made some helpers to deal with links and pushes/redirects dynamically:

@doc """
Uses `Phoenix.LiveView.push_patch/2`, `Phoenix.LiveView.push_navigate/2`, or
`Phoenix.LiveView.redirect/2`, depending on whether the given URL is in the
same live session or live view.

## Example

    push_dynamic(socket, to: ~p"/some/path")
"""
@spec push_dynamic(Phoenix.LiveView.Socket.t(), keyword) ::
        Phoenix.LiveView.Socket.t()
def push_dynamic(socket, opts) do
  url = Keyword.fetch!(opts, :to)

  case navigation_type(socket, url) do
    :patch -> Phoenix.LiveView.push_patch(socket, opts)
    :navigate -> Phoenix.LiveView.push_navigate(socket, opts)
    :href -> Phoenix.LiveView.redirect(socket, opts)
  end
end

@doc """
Takes the socket and a link URL and returns a list with a single `patch`,
`navigate`, or `href` attribute, depending on whether the given URL is in the
same live session or live view.

## Example

```heex
<.link {resolve_link_attrs(@socket, ~p"/some/path")}>Go</.link>
```
"""
@spec resolve_link_attrs(Phoenix.LiveView.Socket.t() | nil, String.t()) ::
        [patch: String.t()] | [navigate: String.t()] | [href: String.t()]
def resolve_link_attrs(%Phoenix.LiveView.Socket{} = socket, url) do
  [{navigation_type(socket, url), url}]
end

# there is no socket in static views
def resolve_link_attrs(nil, url), do: [href: url]

defp navigation_type(%Phoenix.LiveView.Socket{} = socket, url) do
  current_view = socket.view

  # is nil during disconnected mount
  current_session = Map.get(socket.private, :live_session_name)

  case live_session(socket, url) do
    {:ok, ^current_view, ^current_session} -> :patch
    {:ok, _, ^current_session} -> :navigate
    _ -> :href
  end
end

defp live_session(
       %Phoenix.LiveView.Socket{host_uri: %URI{} = host_uri} = socket,
       url
     ) do
  case Phoenix.Router.route_info(
         socket.router,
         "GET",
         url,
         to_string(host_uri)
       ) do
    %{plug: Phoenix.LiveView.Plug, phoenix_live_view: lv} ->
      {view, _action, _opts, live_session} = lv
      {:ok, view, live_session.name}

    %{} ->
      {:error, :not_a_live_view}

    :error ->
      {:error, :not_found}
  end
end

defp live_session(
       %Phoenix.LiveView.Socket{host_uri: :not_mounted_at_router},
       _
     ) do
  {:error, :not_mounted_at_router}
end

This relies on the specifics of the route_info details, and on socket.private.live_session_name. I’m also not sure whether it’s correct to read `socket.view` here, or whether it would need to be socket.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

woylie OP

If you patch to the current route, handle_params is always called, even if there are no parameters. If you use resolve_link_attrs from the example above in your main navigation, you’ll get an UndefinedFunctionError whenever some clicks on the navigation link to the current view if that view does not have a handle_params function. Unless you want to add dummy handle_params functions to all LiveView modules, you may want to map patch to navigate (or rewrite it to not reuse the navigation_type function):

  def resolve_link_attrs(%Phoenix.LiveView.Socket{} = socket, url) do
    case navigation_type(socket, url) do
      :patch -> [{:navigate, url}]
      navigation_type -> [{navigation_type, url}]
    end
  end
steffend

steffend

Phoenix Core Team

LiveView 1.2.10 adds navigation_type/2!

— All posts loaded —

Where Next? Top

Trending in Proposals: Ideas Top

woylie
We are seeing a lot of warning logs like this: navigate event to "https://someurl" failed because you are redirecting across live_sessio...
New

Other Trending Topics Top

mudasobwa
I am happy to introduce the very α version of the new programming language compiled to BEAM. Welcome Cure. It has literally three kille...
New
marciok
Hi there! We created Gust: A task orchestrator inspired by Airflow. For those who have never heard about Aiflow, it’s a Python-based wor...
New
jimsynz
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
Dmk
Xamal is a deployment tool for Elixir apps that deploys native releases to bare metal servers over SSH. It’s a port of GitHub - basecamp/...
New
netoum
Corex is an accessible, unstyled UI component library for Phoenix that integrates Zag.js state machines using Vanilla JavaScript and Live...
New
webofbits
With AI doing more of the implementation work, I’ve been wondering how much coding I should deliberately keep doing myself. My main conc...
#ai
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews