[v6] [Feature]: Declarative routing based on search params

[AHBruns]

What is the new or updated feature that you are suggesting?

I think we should be able to route based on search params in a similar manner to how we route based on pathname. This idea was spawned from this tweet.

For instance, in an app I'm currently working on we have a list of charts that can be hidden, and we need to support link sharing so the hidden/showing state needs to be in the URL somewhere. The list is hidden when either the page search param is missing or the hideList search param is set to true. Right now I start the <ChartsList /> component by checking the current search params via useSearchParams and returning null if the conditions for hiding it are met.

In my mind, I'd like to do:

import ChartsList from "./ChartsList"
import { Route, searchParam } from "react-router-dom"

...

<Route path="charts" searchParams={{ page: searchParam.exists, hideList: "true" }} element={<ChartsList />}  />

Notice that this lets me not only pattern match based on search params, but it gives me a way to express a requirement that a param exists with any value vs exists with a specific value. I imagine searchParam.exists would be a symbol. Ideally this would also allow exclusion via searchParam.doesNotExist. Also, an exactSearchParams prop to enforce no extra searchParams would be nice though I almost think that's an anti-pattern we should prevent people from falling into.

An open question would be how to support params with a list of available values. I'd lean toward allowing predicate functions as values. Then we can dynamically determined which values are okay. Seems cool though, maybe a bit overkill. Something like:

<Route path="/" searchParams={{ date: (param) => param > Date.now()  }} element={<ShowMeTheFuture />} />

Additionally, just like createSearchParams this API should allow the same shorthand syntax that createSearchParams does.

Only thing that I'm not sure about is ordering. A pathname is inherently ordered, but search params aren't, but also kind of are. Like, if I don't duplicate any keys I generally just treat them as a set, but if I duplicate some keys, I have to think about order. So, the question becomes should the following match dogs?x=b&x=a?

<Route path="dogs" searchParams={{ x: ["a", "b"] }} element={<X />} />

If yes, then how would we implement the following?

<Routes>
  <Route path="dogs" searchParams={{ x: ["a", "b"] }} element={<X />} />
  <Route path="dogs" searchParams={{ x: ["b", "a"] }} element={<Y />} />
</Routes>

Obviously, the intent is to choose one or the other based on order, but if order doesn't matter the first would always be matched. With this in mind, I think we need to say order matters, then for situations where we don't care about order we'd use a predicate function like the following.

<Route path="dogs" searchParams={{ x: (param) => param.includes("a") && param.includes("b") }} element={<X />} />

This seems pretty verbose for the default case though. So, maybe invert it and say order doesn't matter then when you need to care about ordering you have to use a predicate function?

Anyways, I'm sure I've only thought about a fraction of what's need to do this well. I'd love to hear other people's thoughts!

Why should this feature be included?

The value here is pretty clear. With this API you'd no longer need to access search params via useSearchParams to make what amounts to a routing decision. You'd be able to make all routing decisions declaratively.

[milieu]

I'd like to propose an alternative syntax for when order doesn't matter:

  <Route path="dogs" searchParams={{ x: new Set(["b", "a"]) }} element={<X />} />

I think it makes a lot of sense to make this logic declarative. It makes understanding this flow a lot more intuitive and less roundabout.

[AHBruns]

Oh, that's very nice. I do wonder if maybe defaulting to ["b", "a"] being unordered and making the very rare case that you care about ordering slightly more difficult by requiring a predicate function is a worthwhile trade-off, but if it's not, new Set([...]) being unordered and [...] being ordered is pretty great. Also, you're right that it's more obvious that ordering doesn't matter when using a set vs when using a predicate function.

[mjackson]

Just a thought: what if it were all encoded in the <Route path> prop? We already use the word "path" in the history library to mean "pathname + search + hash". Maybe something like:

<Route path="products?type=shoes" element={<Shoes />} />

If you're not looking for a particular value, but merely the existence of a query param, you could just leave off the value:

<Route path="posts?date" element={<PostsSearchByDate />} />

Obviously not quite as powerful as the functional matching you're proposing above @AHBruns, but I do like how simple it is to read. And I think we can probably nail 90% of the use cases too.

[milieu]

Just a thought: what if it were all encoded in the prop?

Trying to do a quick and dirty migration to v5.3 from v4 right now for an app that is going to die in a month, just to get past some dependency hell with a monorepo using multiple versions of react-router-dom. Really wishing this feature existed right now.

Besides alleviating my immediate pain, not exposing functional matching forces users to overhaul their routing in order to make their frontend architecture make sense.

I don't believe routing (a backend-driven domain) should act as a leaky abstraction into frontend architecture.

To be fair, for most users the frontend needing better routes will simply result in coordination with a backend team to redefine their contract. But why not prevent dependency coupling when you can?

If this feature existed, then a frontend team could implement their ideal refactor of components ahead of time, and once the backend endpoints caught up to the new agreement the update would be relatively straightforward.

With fullstack devs this is less of an issue, but in a corporate setting I would much prefer not needing to depend on external teams if I can help it.

[Santas]

Any chance of it coming to v6?

[AHBruns]

@mjackson, I think that'd be a good complexity to power solution. It'd also be possible to build libraries on top of that API for more complex usage. E.g. accept a function to generate a description of param requirements then compile the result to a single which gets passed to the underlying route component.

[MeiKatz]

I again propose a validate prop where you could define your own (additional) check function for routes: if it returns a truthy value, the route matches. Otherwise it will not match. As prop you could get the current path and maybe some other properties, like the current search parameters. That would allow any kind of additional functionally, even some we haven't thought about yet.

[richardscarrott]

I'm guessing a suitable place for this as of 6.4 would be in the loader fn?

// ...
{
  path: 'search-params-validation',
  loader: ({ request }) => {
    const url = new URL(request.url);
    const query = Object.fromEntries(url.searchParams.entries());
    const validator = object({ sort: oneOf('ASC', 'DESC') }, { allowUnknown: true });
    if (!okay(query, validator)) {
      return redirect('/');
    }
    return json({ query });
  },
  element: <>Success</>
}
// ...

However, at least in Remix, I presume this would result in a server request, even though technically it could be executed just fine client side?

[patrikholcak]

Is this blocked because of remix file based routing?