Programmatic access to Phoenix Routes

axelson · March 8, 2019, 4:07am

Is it possible to have programmatic access to Phoenix Routes? We are using an instance of a Phoenix.Router to generate in-app links (think myapp://users/42) and I would like to create an admin page that’ll show all the available routes (and generate them with the given ids) but I don’t see any way to introspect the routes. Is it possible? It looks like I could poke in MyApp.AppLinkRouter.__routes__ but that relies on Phoenix internals, so I’d prefer to use a different method.

blatyo · March 8, 2019, 4:16am

I checked to see what mix phx.routes uses and it uses __routes__, so I suspect that’s the only option.

github.com

phoenixframework/phoenix/blob/master/lib/phoenix/router/console_formatter.ex#L9


defmodule Phoenix.Router.ConsoleFormatter do
  @moduledoc false
  alias Phoenix.Router.Route


  @doc """
  Format the routes for printing.
  """
  def format(router, endpoint \\ nil) do
    routes = router.__routes__()
    column_widths = calculate_column_widths(routes, endpoint)


    routes
    |> Enum.map_join("", &format_route(&1, column_widths))
    |> Kernel.<>(format_endpoint(endpoint, column_widths))
  end


  defp format_endpoint(nil, _), do: ""
  defp format_endpoint(endpoint, widths) do
    case endpoint.__sockets__() do

chrismccord · March 8, 2019, 4:51am

There is no public API for this today, but I can see how it could be valuable. In this specific case, it sounds like it would be better to use the existing route helpers given that you have a list of resources or ids? For example:

<%= for user <- @users do %>
  <%= link "user #{user.name}", to: Routes.user_path(@conn, :show, user) %>
<% end %>

Is the discoverability of routes necessary in this case, specifically since you have “(and generate them with the given ids” as part of the requirements? If you have ids, they belong to some resource or subset of resources, which means you need to know up from which routes they belong to, which means programmatic access won’t gain us anything in this case? I could be missing the full requirements, so let me know if I’m off base

axelson · March 8, 2019, 6:49pm

The discoverability of the routes is the main point in this case. Basically I want to render a page (for admins-only) that a similar graphical representation to mix phx.routes (the generation of example concrete routes would just be a bonus).

kidbombay · May 7, 2020, 6:53pm

Can I propose we document this routes feature?
I’d like to use in my app to create a blocklist of invalid usernames for a root route like /username
This is common in many social apps to have a root username route.

It seems like the method is stable as it hasn’t changed in 5 years?

silverdr · August 8, 2021, 7:13pm

Another potential use case (unless a better way is well-known to phx experts): I want to go through all the defined routes testing responses for specific users/roles. It would be good not to have to maintain a separate set of routes to test.

sb8244 · August 9, 2021, 1:15am

I’m sure that most people might recommend against it, but it seems okay to use the private __routes__ function to build this type of thing.

I’d say to not use it in a public OSS library that other people need to rely on, but for private applications and tests it seems alright. The only downside is you need to make sure it still works when you upgrade Phoenix. But you could make an upgrade checklist, or better yet write a test.

silverdr · August 9, 2021, 8:45am

Right, I’ll take this - nomen omen - route since there seem to be no publicly documented way of obtaining all routes. Still wondering why this has to be “private” though. There are valid use cases for this function…

LostKobrakai · August 9, 2021, 8:54am

Having public access to it effectively prevents the ability to refactor. If the phoenix team finds ways to optimize the router by changing e.g. how routes are aggregated they can no longer do that without it being a breaking change. Some addtional API would retain the ability to refactor internals and staying compatible with existing consumers.

chrismccord · August 9, 2021, 4:26pm

Something public is a reasonable ask, but as @LostKobrakai said it has maintenance implications for the team and I’m not yet convinced it’s something we want to offer. For example, in your scenario it may be nice for at-a-glance testing, but fully automating this kind of roles check is not a complete solution because the Phoenix router is not necessarily the extent of all reachable paths in the app. You could have endpoint plugs matching on the path and routing to a separate router for example, or plugs doing dynamic route dispatch based on routes stored externally, etc. We also have things like forward and get "foo/*" which operate on patterns so some level of route building is unavoidable. I’m not saying we’ll never add this, but I hope that helps give some insight

silverdr · August 9, 2021, 11:10pm

Sure. That’s a different story though. If a dev steps out of the Phoenix router, it’s his responsibility to extend the tests accordingly. Kinda Captain Obvious

Understood. And NP, I can live with what I have now.

chrismccord · August 10, 2021, 2:20am

In the context of automated specific users/roles, it’s not “obvious” in that the tests give you a false sense of confidence if that’s what you’re relying on. Also note the point about having to build dynamic paths even under simple scenarios forward, get "/files/*, and even get "/org/:id/payments/:payment_id etc. Route helpers may or may not exist to help you build these, but you can’t completely automate it. Especially for “role” access it gets very tricky on who has access to what. It may be basic “admins” only on route A, B, C, but it may also be role within org having access to payments, etc so it can’t simply be route based to enforce role access. I’m not convinced the stated usecase is the best way to go about testing these things is what I’m saying

silverdr · August 10, 2021, 7:19am

Roger. I see your point.

deepankar-j · November 23, 2021, 7:39pm

I have a scenario that can benefit from being able to introspect the current route of a LiveView. The problem might be solvable without route introspection, so I’ve outlined the use case in the following issue, in case anyone is interested.

github.com/phoenixframework/phoenix_live_view

Unable to differentiate between url params and query params

opened 07:29PM - 23 Nov 21 UTC

deepankar-j

**Problem:** Currently, there's no way for a LiveView to differentiate between …the url params (i.e. those appearing in the router) and query params. **Use Case:** I'd like to have a LiveComponent within my LiveView, which consumes uri + params that the LiveView's handel_params/3 receives. As appropriate, the LiveComponent either adds or removes its own query params and uses push_patch/live_patch to apply the changes. The parent LiveView shouldn't have knowledge about the specific query params that the child adds. It should simply pass along all of the query params to the child LiveComponent. Unfortunately, if the LiveView route includes a url parameter, for example `/orders/:id` and page loaded is something like, `https://localhost/orders/123?tab=1`, the `handle_params/3` callback merges the query params and the url params. When I pass the query params to the child LiveComponent and it eventually composes a URL from the params, it will be something like `https://localhost/orders/123?tab=2&id=123` because the `id` was part of the `params` map passed to the component. **Why not just drop the known URL param from the map before sending it to the child?** Indeed! That's the workaround we're applying now, but it would be nicer to have a more generic solution. **Opportunity for improvement with server-side hooks** With the introduction of server-side hooks, we'd like to put in place a hook that automatically puts the URI and query_params in the assigns of the socket. Right now, we have to configure this hook for each LiveView we use it in. For example: ``` # LiveView's mount function... def mount(_params, _session, socket) do socket |> AssignUrlContextHook.attach(url_params: ["id"]) |> then(& {:ok, &1}) end # AssignUrlContextHook... def attach(%Socket{} = socket, opts \\ []) when is_list(opts) do url_params = Keyword.get(opts, :url_params, []) socket |> attach_hook(:assign_url_context, :handle_params, fn %{} = params, uri, socket when is_binary(uri) -> uri |> UrlContext.from_uri(url_params, params) |> then(&assign(socket, :url_context, &1)) |> then(&{:cont, &1}) end) # UrlContext... def from_uri(uri, url_params, %{} = params) when is_binary(uri) and is_list(url_params) do parsed_uri = uri |> URI.parse() query_params = params |> Map.drop(url_params) %__MODULE__{ uri: parsed_uri, query_params: query_params } end ``` If we had some way of knowing what the URL param name is for a route, we could put this hook within the `router.ex` file and not have to configure it in every LiveView.

axelson · April 26, 2022, 12:44am

It didn’t make the changelog but Phoenix 1.6.x now includes Phoenix.Router.routes/1

It was exposed in this commit: