ream88
Hello,
I’m currently facing a challenge with my Phoenix app, which displays statistics about the products we support. I’m extending its functionality to allow users to specify a date range route parameter to filter the statistics. My goal is to define /stats and /stats/:range in my router.
However, I already have a /stats/:country route that takes a two-character ISO country code, such as /stats/AT for Austrian statistics.
live "/stats", StatisticsLive.General
live "/stats/:country", StatisticsLive.ByCountry
live "/stats/:range", StatisticsLive.General
These two routes now conflict with each other, and I can’t define constraints like in Rails using the :constraints option (at least that I know of).
I now tried the following, because I have a fixed list of countries:
live "/stats", StatisticsLive.General
for country <- Countries.all() do
live "/stats/#{country}", StatisticsLive.ByCountry, String.to_existing_atom(country)
end
live "/stats/:range", StatisticsLive.General
This works by misusing the live_action value passed to the LiveView. However, I need to convert the values to atoms back and forth, can’t access the value via the params map, don’t see it in logs, and overall, it just doesn’t feel right.
Is there a reason why this syntax isn’t currently supported?
for country <- Countries.all() do
live "/stats/#{country}", StatisticsLive.ByCountry, params: %{country: country}
end
I don’t want to introduce a custom plug for this, as it reduces the clarity and visibility of my routes.
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
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
- #blog-post
- #ai
- #phoenix_html
- #iex
- #elixirconf-us
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming










Showing Posts 1 to 6- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
thiagomajesk
I don’t recall Phoenix ever supporting route constraints because you can just use pattern-matching to emulate the same behavior (although I agree it could be useful as it’s more explicit and allows for conditional dispatching). The way I’d go about this is just specifying different routes, so
live "/stats/country/:country"andlive "/stats/range/:range". You always have the option to keep using live actions andhandle_paramsto handle constraints.sodapopcan
Routes are compiled so I don’t think something like Rails’ regex-based constraints could ever be possible. I also don’t see a big difference between
params: %{country: country}and your live action approach.I agree with @thiagomajesk that having sub routes is the way to go, but if you really don’t want to, I would make live components for each stat type and delegate in the router:
That’s just a high-level example and I’m leaving out some context—there are several ways you could accomplish this.
KP123
Am I correct in assuming that the resource is “stats” and that country and range is just a filter over those resources? If so then use a query parameter. Something like
/stats?country=us&range=1-5Edit: This has the benefit of allowing the user to select a range in a specific country instead of one or the other
ream88
I will also introduce the
:rangefilter to the country URLs like this:/stats/AT/yesterdaysodapopcan
What’s the usecase for wanting URLs like this? Is there a big difference between
ByCountryandGeneral? Otherwise, filters like these are exactly what query parameters are for.KP123
I’d still use query params for this. Instead of
rangeI’d usefrom. Then you can have ranges displayed like so:/stats?from=2024-20-06&to=2024-30-06/stats?from=2024-30-06&to=2024-30-06/stats?from=yesterdayAnd of course every filter you dream up in the future just works
/stats?from=today&country=fr&future-filter=argYou could even do
/stats?yesterday. Paths are for hierarchical data, query params for key-value data