🗺️ RFC: Optional Route Segments

[brophdawg11]

Proposal

Add support for optional route segments in react-router by using a ? as the last character in a path definition segment. When a path segment ends in a question mark, the entire slash-delimited segment will be considered optional.

This solves a few types of use-cases:

• Optional static segments
  • /home? to support aliasing / and /home
• Optional dynamic params
  • /dashboard/:widget1?/:widget2?/:widget3? to render a dashboard with an optional number of widgets
  • /:lang?/posts/:slug to make the default language optional (alias /posts/spaces-or-tabs and /en/posts/spaces-or-tabs)

Roadmap and Related Issues

• 🗺 Roadmap Entry: 🗺 Optional Route Segments #9546
• Related Issues:
  • V6: Optional parameters #7285
  • Optional URL parameters #9208
  • [Feature]: Optional routing parameters in v6 #8381
  • [v6] concerning optional URL params #8566

Background

We'd like to add optional routing segments back into react-router. Thus far, the recommendation has been to manually duplicate your routes:

// v5
<Route path="/projects/:id?" element="<Projects />" />

// v6 recommendation
<Route path="/projects" element={<Projects />} />
<Route path="/projects/:id" element={<Projects />} />

This works for simple cases, but doesn't scale well to larger cases. Here's two specific examples:

1. Multiple repeated optional params:

// v5
<Route path="/dashboard/:widget1?/:widget2?/:widget3?/:widget4?" element={<Dashboard />} />

// v6 recommendation
<Route path="/dashboard" element={<Dashboard />} />
<Route path="/dashboard/:widget1" element={<Dashboard />} />
<Route path="/dashboard/:widget1/:widget2" element={<Dashboard />} />
<Route path="/dashboard/:widget1/:widget2/:widget3" element={<Dashboard />} />
<Route path="/dashboard/:widget1/:widget2/:widget3/:widget4" element={<Dashboard />} />

2. Optional routes at the beginning of a path (i.e., /product/slug and /en/product/slug)

// v5-ish - unsure if this is totally valid v5 syntax :)
<Route path="/:lang?" element={<Layout />}>
  <Route index element={<Home />} />
  <Route path="home" element={<Home />}>
  <Route path="category/slug" element={<Category />}>
  <Route path="product/:slug" element={<Product />}>
</Route>

// v6 recommendation
<Route path="/" element={<Layout />}>
  <Route index element={<Home />} />
  <Route path="home" element={<Home />}>
  <Route path="category/slug" element={<Category />}>
  <Route path="product/:slug" element={<Product />}>
</Route>
<Route path="/:lang" element={<Layout />}>
  <Route index element={<Home />} />
  <Route path="home" element={<Home />}>
  <Route path="category/slug" element={<Category />}>
  <Route path="product/:slug" element={<Product />}>
</Route>

Note that in the second example, we even have a use-case for an optional state route segment in / and /home wanting to use the same route element, thus effectively leading to a desire for /home?.

Approach

The general idea for the approach is to allows users to "define" routes with optional params, but then we will automatically explode them into their enumeration of non-optional possibilities. This is effectively doing exactly what we ask users to do manually today. By doing it this way, we ensure that ranking/scoring all still works exactly the same - and it's as-if the user specified all those route paths individually. In the below example, the /:p1/:p2/:p3 path would have the highest score and would take precedence over it's shorter-path siblings.

// User <Route> definition 
<Route path="/p1?/:p2?/:p3?">

// Internal exploded route representations
[
  { path: "/" },
  { path: "/:p1" },
  { path: "/:p1/:p2" },
  { path: "/:p1/:p2/:p3" }
]

In order to implement this in such a way that it works for non-data-routers (i.e., BrowserRouter) and data-routers (RouterProvider), we have to perform this explosion during the current matching algorithm, presumably inside of flattenRoutes.

Pros

• Leaves route scoring/ranking logic untouched
• Does not require duplicate implementation, since BrowserRouter and RouterProvider use the same route matching logic
• The user-defined routes remain untouched, as we only explode these when we go to explode/match, therefore in data-routers useMatches will still return the defined route with a ? in the path

Cons

• Adds some small overhead to matching logic, but we have separate optimizations planned in that space (future RFC coming 😉) and I don't foresee this aspect prohibiting those approaches

Remix Considerations

This route duplication is also painful in Remix, as shown by the duplication in Jacob's e-commerce example:
https://github.com/jacob-ebey/remix-ecommerce/tree/main/app/routes and https://github.com/jacob-ebey/remix-ecommerce/tree/main/app/routes/%24lang. So we'd want to support this in the conventional routes as well - presumably with just a ? in the file name:

• app/routes/home?.tsx
• app/routes/$lang?.tsx

This will be a fast-follow undertaking to add support for optional route segments to Remix's conventional routes generation - potentially something that makes sense to do along with the Flat Routes. However, once this is implemented in react-router-dom and Remix is leveraging the updated version I think folks would be able to leverage this via defineRoutes.

[kiliman]

When this PR remix-run/remix#3970 lands, it should be relatively straightforward for Remix route config to generate multiple routes to the same file.

FYI: ? is considered a wildcard in Windows, and not a valid filename, so maybe not a good candidate for file-based routing.

[ryanflorence]

Been thinking about it and I think I'd go with parens products/($category)/$pid