Dynamically construct path by action and helper name

That’s such an interesting question, shame nobody chimed in.

A more-explicit approach would be to ask users to configure your library with a {module, function, args} tuple that can generate the route.

For instance, you might configure {MyAppWeb.LibHelper, :my_lib_route, [:extra1, :extra2]} and define:

defmodule MyAppWeb.LibHelper do
  def my_lib_route(conn, params, _extra1, _extra2) do
    # extra1 and extra2 are just to show what happens
    MyAppWeb.my_lib_path(conn, :library_action, params)
  end
end

Your library could call this with:

def call_route({mod, fun, args}, conn, params) do
 apply(mod, fun, [conn, params] ++ args)
end

Thanks for pinging this thread back into view. The possibility that helpers generation goes away also impacts localized route generation and localized helpers.

Both @BartOtten’s phoenix_localized_routes and my own ex_cldr_routes use helpers to generate routes at runtime to reflect the locale in effect at the time. This cannot be parsed at compile time because at that time the locale is not known.

Localized routes have the same helper name and same path structure but have path components translated (and may have locale components interpolated).

For that reason alone I hope that Helper generation can have a more definitive future.

I like this approach. There are a few places in the library where I plan to do this or something very similar. Especially if I can find a way to make the existing route helpers module meet the contract as well.

I certainly agree. Verified Routes is a powerful addition to Phoenix, and — just to be clear — I fully support it as the default for consumers. Maybe there is a different mechanism that would support 3rd-party libraries like the route helpers do now. Perhaps something with a bit less metaprogramming magic (since we wouldn’t be optimizing for the ergonomics of calling a helper function with exactly the right number of arguments). Not sure what that might look like, but the intersection of our use-cases is quite interesting.

@kip do you have time to talk about it with Phoenix Team? I am living without digital devices as much as possible and the network is really bad over here Will be back in a week, but those 7 days might make a difference.

I wonder why you need the path helper in the first place. conn.script_name should give you the segments of the path, which was used to get to your controller. No need to consult the router or anything. Should work fine with both Plug.Router as well as Phoenix.Router. You can use that to build the path within the code you control. If the user wants to link to your controller they know the necessary details and can just use the normal phoenix tools (helpers, verified routes, …) to do so.

It not really about knowing the path that got to the current controller. It’s generating paths and URLs to other parts of the site, where those paths are localised. Since they are localised the path cannot be validated at compile time (or at least I can’t think of a way). Using helpers give some minimal guarantee since an unknown function error at compile time acts as a signal.

I guess my question was more targeted at @aj-foster’s usecase, which seems to be related to urls to itself, rather than other pages.

Apologies for not being clear. In reality this library has multiple controller actions. I don’t need the path to the current controller action, but rather the path to another controller action also prescribed by the library. Hence the need to look up the action by name/helper.