With the change away from helpers to verified routes, I’m wondering if/how it is possible to invoke a route without knowing the full path including scopes, which was one of the uses of named helpers?
Can you provide an example? Even before, you had to know the name. So if you have some sort of contract, where you were like, give me a module name and it should have this helper, you can still define said contract using functions that returns a verified route (which is just a string anyway),
2 Likes
Sure, I am using the named helper without knowing the rest of the routes here: live_admin/lib/live_admin/view.ex at 5d96eee465ed64dcb90eb616aa55537189beb0e6 · tfwright/live_admin · GitHub
Currently, that returns a path like /admin/my_resource with needing to know about the admin scope in the router the route was defined in. My understanding that the path using verified routes would need to be something like ~p"/admin/#{my_resource}"?
1 Like
This does not answer the question literally, but might present a solution to the problem you are facing.
Your lib seems to accept a scope as option to the macro so this should be possible to generate using the macro:
def resource_path(resource), do: ~p”/admin/#{resource}”
Then you combine a path-less function call with routes verified at compile time.
ps. if you know the resources during compile time too, you can generate more specific function clauses.
def resource_path(%User{} = resource), do: ~p”/admin/users/#{resource}/show”
def resource_path(%Product{} = resource), do: ~p”/admin/products/#{resource}/show”
1 Like
True, and that part of the scope I can handle, but it’s also possible that the routes were defined in other scopes above it, and I’m not sure where to get those.
I don’t see how that issue can be solved without some rewriting of your macro. Wonder where José comes up with (or not).
Currently writing a lib which hooks into the Router using _before compilation_ and is able to write helpers using all information known about routes (including resolved nested scope paths). Copied some docs already to this forum, see paragraph Powerful but thin as it includes some pointers where you could look at.
If you pass me your email by PM I can grand you access to the still private repo and you can let it inspire you (or decide that writing an extension is actually easier ;))
I dug around in the phoenix_live_dashboard source, since it is mounted using almost the exact same strategy (because I shamelessly copied it), and it looks like it takes advantage of a function that looks like it was added in 1.7: Phoenix.Router.scoped_path/2
AFAICT it does exactly what I need–it returns the full path to the current scope, so by invoking it inside the macro I can grab and store the prefix to use when building my routes.
2 Likes
And for anyone else that needs to do something similar, I adapted a combination of the LiveDashboard/Phoenix 1.7 helpers to remove the dependency on named helpers from my app without requiring 1.7: Remove router helpers dependency · tfwright/live_admin@56a3149 · GitHub
1 Like
