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.

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.

In cases where I only need to worry about one level of navigation, what I use is pretty similar to what’s described here, except I use the value of socket.assigns.live_action as the fallback value for what the assign the article calls active_tab instead of nil.

In cases where I have to worry about multiple levels of navigation, I prefer to be even more explicit and will put something like the following in all the LiveViews:

def mount(_, _, socket) do
  assign(socket, nav_root: :account, nav_sub: :preferences)
end

That way when I get a request along the lines of “I know when want everything under /account to market the ‘Account’ link as active, except when they are on /account/xyz then we want ‘Foo’ active.” I open up that one LiveView file, add assign(socket, :nav_root, :foo) and move on.

If using the current URL works for you in marking your nav items as active/inactive then that’s great. I personally wouldn’t be passing the URL/path to the templates do the active/inactive check down at that level. Instead, I would use a handle_params hook that sets an assign based on the URL, that way in those exceptional cases the value can be easily overridden in the respective LiveView.