Is socket-based navigation on LiveView's roadmap?

Phoenix Forum Proposals/Suggestions
1

On a Rails/Turbo site, the first page is typically loaded using http GET and then sockets are used navigate and replace HTML content for the remainder of the session.

LiveView is amazing for interacting within a page but I find that having a GET request when switching pages can make the experience a bit less smooth.

So I’m wondering… is it on the roadmap for LiveView to handle not only patches but also navigation requests purely over sockets?

1 Like
2

That’s how it works today!

You can do patches within the same LV, navigate through the socket between LVs and do full page loads to other parts on the app (non-LV).

3 Likes
3

This was already implemented years ago :smiley:

https://hexdocs.pm/phoenix_live_view/live-navigation.html

Basically you’ll want to use <.link navigate=…> or <.link patch=…> instead of href (or the corresponding push_navigate/push_patch functions). Also, the LiveViews you’re navigating between should be part of the same live_session.

3 Likes
4

You‘re too fast! :smile:

1 Like
5

Switch to live sessions and you’ll be able to navigate through live views without doing the whole HTTP round trip.

1 Like
6

Wow, thank you all! My initial understanding from watching the LiveView videos was that it worked this way, but then I started using <.link> with href and was surprised it would do a full GET every time. :face_in_clouds:

I had assumed that since a route can either be LiveView or “dead view” but not both, the code would use the most efficient way to load the page content. This would be costly at runtime but maybe could make sense in a macro?

7

You could do navigate everywhere and it’ll afaik fall back to http requests for non-live routes.

1 Like