aj-foster
Dynamically construct path by action and helper name
Question
Given a route with a known controller action (:library_action) and a known helper name (as: :my_lib), how can I reliably generate the route’s path?
Background
I’m creating a library that integrates with Phoenix. This library provides a controller action MyLib.Controller.library_action/2, and asks consumers to add a route to their application’s router, such as:
get "/user/chosen/path/with/:param", MyLib.Controller, :library_action, as: :my_lib
For flexibility, I require the name of the action (:library_action) and the :as option, but leave the exact path up to the consumer. Furthermore, the consumer may choose to reimplement the :library_action controller action in their own application, ignoring the one provided by the library.
Whether the consumer uses the library-provided implementation or substitutes their own controller, it is necessary for other parts of the library to know the path for this action. In the past, the library could rely on the router’s Helpers module, and use the generated my_lib_path(conn :library_action, ...) function to create the path or URL. However, with Phoenix 1.7, the Helpers module is no longer guaranteed to be generated.
Other Notes
Here’s what we can do already:
- Get the current router dynamically from the
connviaPhoenix.Controller.router_module/1. - Get a list of known routes via
Phoenix.Router.routes/1. - Filter by the
helperandplug_optskeys to find a route with the correct action name and:asoption. - Get the full path as a string, for example
"/user/chosen/path/with/:param". - Manually replace path segments with values, when necessary.
However, this process seems error-prone, especially the manual replacement of path segments.
All suggestions welcome! Thank you.
Most Liked
kip
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.
dimitarvp
That’s such an interesting question, shame nobody chimed in.
LostKobrakai
Translations are available at compile time, so I feel like it should be possible to figure out the language dependent segments at compile time and then return something akin to this:
# ~x"/pages/#{@page}"
case @locale do
:en -> ~p"/pages/#{@page}"
:es -> ~p"/paginas/#{@page}"
:de -> ~p"/seiten/#{@page}"
end
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance








