Heres how I do it.

1. Define a liveview mount hook.

defmodule MyAppWebWeb.Hooks.DefaultHooks do
  import Phoenix.Component
  import Phoenix.LiveView

  def on_mount(:default, _params, session, socket) do
    socket = attach_hook(socket, :current_path_hook, :handle_params, &put_uri_hook/3)
    {:cont, socket}
  end

  def put_uri_hook(_params, uri, socket), do: {:cont, assign(socket, uri: uri)}
end

2. Call this in hook in your routes, then the @uri will be available in assigns in your liveview, you can pass it down your component as attribute.

Thanks kamaroly

Is there nothing as a built in option for such a standard thing?

The current URI is available in the handle_params/3 callback of every LiveView, and there are mechanisms available in the framework to reduce repeated application logic. What’s suggested here is a good example of using those available mechanisms to set the URI in the assigns of every LiveView (without much code, IMO).

What were you hoping the “built in option” would work?

I think for people who are coming from all-batteries-and-your-grandmother-included frameworks are confused when not everything is built into the framework.

Something like “host_uri” from the socket, but this only gives me the domain, not the path.

I’ve got a global menu and in it I want to highlight buttons of the menu if they are selected. When clicked, the button takes you to a route and the logic would be “if the current_path is /example then highlight button “example”

My menu is in the “app.html.heex” and it only got “socket”, no “conn”

Thanks @jswanner . I tried to modify the handle-params in one of the live views by adding the url, but got different errors later in heex saying that I can’t use handle_params in a child LiveView . And even if I could, I would need to add this option manually to every liveview that is connected to a menu button.

Anyway, after trial and error, huffing and puffing, I wrote a JavaScript Hook. Now it all works, but it feels extremely cumbersome for something so small and basic.

PS: the JS hook does not identify the path, it just highlights any button that was clicked

Yes @Stefano1990 , we kind of do. The understanding and the default assumption is that Phoenix is indeed a battery included framework. If it’s got Ecto and database Integration, it’s got authorisation nipped in the bud, It’s got email sending built-in, it’s got live view and pub subs. so yeah, I kind of expect it would be easy to get the current page from the heex template

There’s multiple things problematic with an approach like this:

• The path may change throughout the lifecycle of a LV process, hence it needs to be tracked for changes so templates update when it does.
• LV doesn’t have any built in means of computed derived values. So if you have stuff in your assigns, which are derived from the url that needs to be manually computed in a callback triggered when the url changed (handle_params). If the socket would change without a callback you’d have nowhere to do such computations.
• LV is stateful, so any information forcefully retained by LV does make your memory footprint worse. Hence LV retains the minimal amount of information it can leaving it up to the user to retain any additional information only if needed.

Given those constraints a callback like handle_params and letting all the change tracking work like anywhere else for any other retained custom data makes sense.

To add some context, the reason the current URL isn’t just available to views is that it needs to be stored on the socket (as mentioned above) which isn’t free. Not every application needs it and many applications only need pieces of it (for example perhaps they don’t care about query params or perhaps just the first slash segment) so it’s left up to the developer to decide what to store.

Thanks @sodapopcan @LostKobrakai - I understand the listed reasons, but I still can’t justify them. I don’t know the how, but - if JS can do it, I’m sure Elixir/Phonenix can too and the memory footprint - I don’t think a couple of strings with slashes would clog the socket. I think that if Svelte (as compiled as Phoenix) can be fast and light, Elixir/Phoenix can do too. My take is that the reason for this is more historical and cultural than technical - and it’s fine by me.

I’m not going to win this battle. I’m just looking at it with the eyes of a newcomer and notice what in my opinion is something that is taken for granted elsewhere while that elsewhere is much more primitive (Svelte, Next.js) than Phoenix.

Anyway, if you can’t beat them - join them…

A question about handle_params - I can’t use this approach for all of my menu buttons because one of them leads to a search modal based on a LiveView and my app.html.heex is also backed by a LiveView (no @conn) and If I use handle_params , I get an error
handle_params/3 is not allowed on child LiveViews, only at the root.

What could I do in this case? Thanks

P.S. Here is my repo

The ‘Territory’ menu button is the only one that can’t accept handle-params. The rest of them I adapted to your @LostKobrakai approach. Thanks