Customize params for LiveViews

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.

6 comments

/phoenix #routes

0 495 6

2024-06-30 19:33:20 UTC

Showing Posts 6 to 1

Show Best Posts
Show All (oldest first)
Show All (newest first)

KP123

I’d still use query params for this. Instead of range I’d use from. Then you can have ranges displayed like so:

Range of days: /stats?from=2024-20-06&to=2024-30-06
A specific day: /stats?from=2024-30-06&to=2024-30-06
Special case values: /stats?from=yesterday

And of course every filter you dream up in the future just works /stats?from=today&country=fr&future-filter=arg

You could even do /stats?yesterday. Paths are for hierarchical data, query params for key-value data

Post #6

sodapopcan

What’s the usecase for wanting URLs like this? Is there a big difference between ByCountry and General? Otherwise, filters like these are exactly what query parameters are for.

Post #5

ream88

I will also introduce the :range filter to the country URLs like this: /stats/AT/yesterday

Post #4

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-5

Edit: This has the benefit of allowing the user to select a range in a specific country instead of one or the other

Post #3

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:

def render(%{param: param} = assigns) when param in @countries do
  ~H"""
  <.live_component id="countries" module={MyAppWeb.CountryStatsComponent} countries={@countries} />
  """
end

def render(assigns) do
  ~H"""
  <.live_component id="range" module={MyAppWeb.RangeStatsComponent} ranges={@ranges} />
  """
end

That’s just a high-level example and I’m leaving out some context—there are several ways you could accomplish this.

Post #2

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" and live "/stats/range/:range". You always have the option to keep using live actions and handle_params to handle constraints.

Post #1

— All posts loaded —