Hey @jakeprem,

I was planning to send a proposal to support modifying query parameters through JS.patch/navigate, for example like this:

JS.patch("?foo=bar") # -> sets current page's query parameters to foo=bar
JS.patch(query: %{"foo" => "bar"}, merge_query: true) # -> sets query parameter foo=bar and keeps existing
JS.patch(drop_query: ["foo"]) # -> removes the foo key from query paramters

I think modifying only parts of the URL is important for building complex components relying on URL state, therefore merging and dropping parameters, but keeping unrelated ones should be something we support in my opinion.

In a previous project I did something like this:

def patch_params(%JS{} = js, params, opts) do
  opts = Keyword.validate!(opts, [:type, :path, :remove_params])

  JS.dispatch(
    js,
    "patch-params",
    detail:
      Map.merge(
        %{params: Plug.Conn.Query.encode(params)},
        Map.new(opts)
      )
  )
end

window.addEventListener("link:patch-params", (e) => {
  const type = e.detail?.type || "patch";
  const path = e.detail?.path || document.location.pathname;
  const params = new URLSearchParams(e.detail?.params || "");
  const removeParams = e.detail?.remove_params || [];

  const searchParams = new URLSearchParams(document.location.search);
  Array.from(params.keys()).forEach((key) => searchParams.delete(key));
  Array.from(params.entries()).forEach(([key, value]) => {
    searchParams.append(key, value);
  });
  removeParams.forEach((key) => {
    searchParams.delete(key);
  });
  const search = searchParams.toString();
  const href = search ? (path + "?" + search) : path;
  if (type == "patch") {
    liveSocket.pushHistoryPatch(e, href, replace ? "replace" : "push", e.target);
  } else if (type == "navigate") {
    liveSocket.historyRedirect(e, href, replace ? "replace" : "push");
  } else {
    document.location.href = href;
  }
});

But this also relies on private liveSocket APIs (pushHistoryPatch/historyRedirect), so we should have an official way to do this.

To give some more light on the underlying issue: if you build a complex component that relies on URL state, for example a table with multiple filters (like selected countries, etc.), each filter needs a way to update the URL correctly. One approach that is often used is to store the parameters in the assigns and then construct the link on the server:

def handle_params(params, _uri, socket) do
  socket
  |> assign(:params, params)
  |> assign_country_filter(params)
  |> ...
  |> then(&{:ok, &1})
end

def render(assigns) do
  ~H"""
  ...
  <div id="country-filter">
    <.link :for={country <- @all_countries} patch={~p"/my-live-view?#{Map.merge(@params, %{"country" => country.iso})"}>{country.name}</.link>
  </div>
  ...
  """
end

This approach works, but has the big downside of creating huge diffs over the wire, re-sending each link whenever any parameter on the page changes.

So I’m not sure yet about overloading phx-value-* for JS.patch/navigate, but I’m definitely in favor for a way to manage query parameters without having to deal with the whole URL!

I mean - a prototype kind of exists with the code I shared - the main thing is coming up with a nice API that makes sense next to the existing JS.navigate and JS.patch functions. If you want to have a go at that, I’m happy to comment on whatever you propose!

Yeah, sorry, that’s what I meant by prototype. Something that could be reviewed for api compatibility and all that. I’ll give it a shot. Thanks!

Upvote this effort. Wanted just this today.

@steffend Was this implemented or is it still in the proposal phase? Would you be willing to accept a PR if the design has been approved? This would be a very helpful feature for a project I’m working on.

Specifically, I am working with array-valued keys in the query string for sorting a table with dynamic order, so the query string has something like sort[]=first_col-asc&sort[]=second_col-desc in it along with other params for things like pagination and dynamic filters. I think in addition to the :query and :drop_query options in your mockup, something like JS.patch(filter_query: fn {key, val} -> key == "sort[]" and !String.starts_with?(val, "first_col") end) would be useful for my use-case. Perhaps also a map_query option that takes a similar function over the {key, value} tuple. That would allow for specifying a filter and a map function to do things like sort order cycling on-click:

JS.patch(
  filter_query: fn {key, val} ->
    key == "sort[] and String.starts_with?(val, "first_col") and !String.ends_with?(val, "desc")
  end,
  map_query: fn {key, val} ->
    if key == "sort[]" and String.starts_with?(val, "first_col") and String.ends_with?(val, "asc") do
      {key, String.replace_suffix(val, "asc", "desc")
    else
      {key, val}
    end
  end,
)

I’m sure there’s a more efficient way to do this kind of thing, but the map/filter approach would probably be useful for other situations as well like removing all params with a common prefix that have been added dynamically by a component.

If that kind of api is not desired, I would still be happy to work on whatever the Phoenix team wants to implement for this feature if no one else has already picked it up.