Allow more regex for paths

[dbibbens]

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

update current route.path to allow more conditional regex paths for multiple conditions like in v5.

v5 route: /(wines|whiskeys|sakes|beers)/:id/:productName?

Why should this feature be included?

current v6 doesnt include this anymore. only allow strict routes.

[SafaAlfulaij]

This is what currently stops me from moving to V6. Moving the validation logic to components is not suitable IMOH, and waste resources.

I would suggest that instead of providing arbitrary regex in each path, we define some formats in the config level, then use them within paths. This also could be the only way to use regex within paths.

For example, Router's formatsConfig prop:

{
  "uuid": /([0-9a-f]{8}-[0-9a-f]{4}-[1-5][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12})/,
  "drinks": /(wines|whiskeys|sakes|beers)/
}

Then use them within paths:
Note: The curly brackets is just an example. Any other format that does this is fine.

<Route path="{drinks}/:id{uuid}" element={<Teams />}>
// or
<Route path="{drinks}/id:uuid" element={<Teams />}>
// or
<Route path="{drinks}/{uuid:id}" element={<Teams />}>

Or as a separate validation prop:

<Route path="{drinks}/:id" validate={{ id: 'uuid' }} element={<Teams />}>

Inspired from UI-Router

[wintercounter]

I was also about to open a feature request for a similar case. In my codebase, I heavily rely on path-to-regexp features. The upgrade docs say to move such logic at the component level, but for me, that's not possible, paths are set by users from an admin interface where components don't (and can't) include such logic.

I was thinking if we can have a plugin-like solution where we can supply a pathParser prop to Router. This would allow using any custom solution we need, keeping the base library small and dependency-free, but allowing people to create 3rd party community packages to add support back to path-to-regexp for example. I think this could be a win-win solution for all parties.

[justrealmilk]

While an API for 3rd party path parsing sounds cool, I think this functionality is pretty basic and popular. Unsure why it was removed.

At the top of my switch, I have

<Switch>
  <Route path='/:membershipType([1|2|3|4|5])/:membershipId([0-9]+)/:characterId([0-9]+)?' component={ProfileRoutes} />
  ...

Am I now supposed to write a route for /1-5/?

[nuintun]

https://developer.mozilla.org/en-US/docs/Web/API/URL_Pattern_API

[Vincz]

I agree with all of the above. The pattern matching was handled nicely with v5, why remove such a critical feature?

[queengooborg]

+1 for getting this functionality added back in. Just like optional routing parameters, this was such a useful (and critical feature), and it's not clear why this functionality was removed...we're gonna have to stay on v5 because of it. I'd love to hear a reasoning from the package maintainers as to what led to this surprising and large change.

[wintercounter]

They justified the removal in the changelog/upgrade docs. The main reason is size, `path-to-regexp` is big. I also believe it has to do a bit with `Remix` as they are using file-system-based routing, just like Next and folder/filenames don't support most of the regexp syntax characters. Yet I don't see any reason not to provide an API to be able to extend. Some response from the team would be nice regarding this topic, at least to know if they consider this. Not having this will keep me on v5 forever for sure.

…

On Mon, Dec 6, 2021 at 9:46 PM queengooborg ***@***.***> wrote: +1 for getting this functionality added back in. Just like optional routing parameters, this was such a useful (and critical feature), and it's not clear why this functionality was removed...we're gonna have to stay on v5 because of it. I'd love to hear a reasoning from the package maintainers as to what led to this surprising and large change. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#8254 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHLJQFB3WWYCG2ECRLUN4TUPUOKTANCNFSM5HP3PYKQ> .

[bluepeter]

Likewise. In my opinion, it's a big step backwards. Removing (presumably) widely-used functionality with the terse note only to "remove it and simplify your route paths" is upsetting. It's a massive breaking change. Reducing file size is great, but this feels like an over-optimization at the expense of better functionality and backwards compatibility.

[singggum3b]

A lot of useful feature has been removed from v6. I think overly obsessive with the package size is really weighting on the usefulness of the library. What if the majority of user has to workaround those feature anyway, or just simply refuse to upgrade to v6?

[bluepeter]

The maintainers aren't responding to the concerns. As others mentioned, we are looking into https://github.com/molefrog/wouter as we doubt that v5 will be maintained, and we can't use the reduced feature v6.

[wintercounter]

Nice, the matcher prop does exactly what we wish for here and it has a react-router compatible API. Thanks for sharing.

…

On Mon, Dec 13, 2021, 16:44 bluepeter ***@***.***> wrote: The maintainers aren't responding to the concerns. As others mentioned, we are looking into https://github.com/molefrog/wouter as we doubt that v5 will be maintained, and we can't use the reduced feature v6. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#8254 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHLJQAHDRXPZ2RDLHFUM33UQYIGDANCNFSM5HP3PYKQ> .

[videni]

what is the solution at the moment?

      <Route path="/store" element={ <Products />}>
        <Route  path="nodes" element={<Nodes />} />
        <Route  path="checkout/:productId" element={<Checkout />} />
      </Route >

I got store/checkout/123e4567-e89b-12d3-a456-426655440006 , it always render Products not the Checkout
, but changing uuid to an integer , it works.

[kulakowka]

@videni it's similar to my problem with symbol - #8525

[videni]

@kulakowka, however , it works after changing it to

<Route path="/store" element={ <Products />} />
<Route  path="/store/nodes" element={<Nodes />} />
<Route  path="/store/checkout/:productId" element={<Checkout />} />

[james-Ballyhoo]

Wish I'd known this had been removed before starting a migration from 5 to 6.

The migration docs did not make it clear this would be a breaking change, it's buried half way down the page as a side note.

[VeXell]

+1 This is a good feature. Not with React Router 6.6.1 we have optional params, but i still can not use logic like that:

 const langs = `/:locale(${languages.join('|')})?`;

This is a small validation what language we can use. Instead of this simple logic we should create list of routes with all supported languages.

[brophdawg11]

@VeXell If you need to do param validation, I would do that in a loader where you can then return a 404 or redirect to a known good language URL.

[wintercounter]

So you suggest to add loader to EVERY path and extra check to EVERY loader? Not to mention loaders only work with Data API.

[brophdawg11]

Data Routers are the recommended app setup going forward due to the UX benefits provided by decoupling data fetching from rendering, so we encourage folks to move towards them either way. Keep an eye on the middleware feature to avoid duplication of param validation.

[brophdawg11]

I'm going to convert this to a discussion so it can go through our new Open Development process. Please upvote the new Proposal if you'd like to see this considered!

[VeXell]

@brophdawg11 yes, might be it be helpful, but i did not find any examples how loader works with SSR. For us this function is not flexible because we using redux also and we need access to store, dispatch and some additional params. We implemented own solution how to load data from server code and browser. Moreover it means we should have this check language logic for every route - i guess it is too much. But still, without RegExp pattern (for example we are using for our users routing /:id([a-z0-9_\\-\\.]{4,})) we should make server request to check correct user id, but with V5 router does it without any additional logic. And if path is not correct - just show 404 page. So, from my point of view - RegExp support might be helpful for some cases.

[brophdawg11]

Docs are coming soon for SSR for Data Routers, but here's a sample app using the new createStaticHandler, createStaticRouter, and StaticRouterProvider APIs: https://github.com/remix-run/react-router/tree/main/examples/ssr-data-router.

As soon as the middleware proposal lands (should be starting work on that this week or next) then you won't have to validate in multiple routes either 👍

[MahmonirB]

How can I set Router's formatsConfig, I did not find it in react router v6?

[ericchernuka]

I'm not sure if this is of value to anyone, but I thought of an exciting way to tackle this, avoiding needing to type out each route. To accomplish this, use a layout element "guard" to enforce the specific parameters you want to enforce. If they are valid, then render the outlet for the nested route; otherwise, Navigate or render a fallback. It would look like the following:

<Routes>
  <Route path="/" element={<Dashboard />} />
  <Route path=":lang" element={<LangParamValidator />}>
    <Route index element={<RouteWithLangParam />} />
  <Route>
  <Route path="*" element={<NotFound />} />
</Routes>

function LangParamValidator() {
  const { lang } = useParams<'lang'>()

  if (lang && ALLOWED_LANGS.incldues(lang)) {
    return <Outlet />
  }

  return <Navigate path="/" replace />
}

I tried this in an example when attempting to recreate how Google Calendar handles routing for the views and dates. It's messy, but it can at least illustrate the concept. One thing to note on this is that Stackblitz's route information doesn't update properly so if you'd like to mess around with the routes, you'll need to manually type them in.

You can see my repo here: https://stackblitz.com/edit/vitejs-vite-nxtuof?file=package.json,src%2FApp.tsx&terminal=dev

The neat part about this one is that I leveraged OutletContext to pass default parsed routing information down to all the components so if/when they get rendered, they have a correct Date object.

[jlowcs]

If the goal is to not rely on path-to-regexp, maybe the library could allow us to pass a custom path matching function, which could itself use path-to-regexp if we wanted to get the same behavior as v5?

Something like <Router pathMatcher={pathMatcher}> maybe?

[dangayle]

I had the same idea: #9844 (comment)

[WCByrne]

In the v6 migration guide It says:

If you were using the RegExp syntax to do URL param validation (e.g. to ensure an id is all numeric characters) please know that we plan to add some more advanced param validation in v6 at some point.

Is that bit about adding "some advanced param validation at some point" still relevant?

I have to agree that this feels like a step backwards without even a very basic replacement. Having to do param validation in the component feels like it is mixing routing and component logic.

[gooftroop]

What's the likelihood of adding support for this feature any time soon?

[krukid]

I've managed to work around my specific use case with:

const RegexRoute = () => {
  const { slug } = useParams();
  // slug: my-regex-abc
}

createBrowserRouter(
  [{
    id: 'root',
    path: '/',
    element: <RootRoute />,
    children: [{
      path: '*',
      element: <CatchAllRoute />
    }]
  }],
  {
    async unstable_patchRoutesOnMiss({ path, patch }) {
      // react router 6 does not support path matches by regex, this is a workaround for that
      // https://github.com/remix-run/react-router/discussions/9844
      if (/^\/my-regex-[a-z]{3,10}$/.test(path)) {
        patch('root', [{ path: ':slug', element: <RegexRoute /> }]);
      }
    },
  }
)

See https://reactrouter.com/en/main/routers/create-browser-router#optsunstable_patchroutesonmiss for other use cases.

PS: this even works with all of the fancy handle stuff you may want to look up from RegexRoute in your RootRoute via useMatches

[brophdawg11]

I would not recommend using unstable_patchRoutesOnMiss for this. Once you patch in the path: ':slug' route it will persist and will match any /:slug route in the future, as if you had path: ":slug" in your route tree up front. The regex will thus only ever be evaluated on the very first time you route to a single-url-segment path - but not for any navigations after that because they'll all match :slug and won't call patchRoutesOnMiss

[krukid]

ok how about I patch with the specific matched path vs slug? e.g. patch('root', [{ path: path.slice(1), element... }])

[brophdawg11]

That would work - you'll just end up with a slightly larger than necessary route tree since it's effectively the same as if you had included them as static segments up front - but it allows you to do it dynamically and build that based lon user navigation instead of manually including them all up front.

{ path: '/my-regex-abc': element: <RegexRoute /> },
{ path: '/my-regex-def': element: <RegexRoute /> },
{ path: '/my-regex-ghi': element: <RegexRoute /> },
...

[Bessonov]

Guys, sorry, but you can't be serious. There’s no way this isn’t a bad joke. How many upvotes do you need? This is an essential feature for any router. I ran into this issue with SEO-friendly URLs like /lawler-in-miami, where /lawler-in-:city doesn’t work. How should we approach this issue? Why is there no documentation for a workaround?

Of course, this is open source, and everyone can contribute, but it seems like the maintainers don’t want this feature to become a reality in any way.

[Bessonov]

As a workaround I went with matching /:slug, extracting the city part and passing it to a component...

[xaota]

link this proposal please, it's resolves the same problem

#12175

[PenghaiZhang]

I come here to request getting this feature back. In our 20 years old products, we have to support some legacy paths for those old clients. In v5 we simply do `path: "oldPath|newPath". Very clean and readable.

[zLikeMario]

Perhaps I'm really not suitable for using react.

[Silviu-Marian]

Had ternaries in the route definitions in v5 so our routes.js file is quite used to them.

If you're okay with them, it's quite easy:

  const { pathname } = useLocation()
  const isIndexPath = pathname?.match(/^\/index\.[a-zA-Z]+$/i) // or whatever RegExp you require

  return (
    <Routes>
      {isIndexPath ? <Route path={pathname} element={<Navigate to='/' replace />} /> : null}

and then there's no need to wait for any other feature.

[dangayle]

I've been working on a branch that uses a minimal, opt-in “pluggable matcher” design that keeps current behavior by default. The core is a RouteMatcher interface with matchPath + matchRoutes, and a setRouteMatcher() API to swap in a custom implementation. The default matcher just wraps the existing logic so there are (should be?) zero breaking changes.

This would let teams plug in alternate matchers (e.g. regex/named captures or a Hono-style router) without touching React Router’s internals, while leaving existing users unaffected. I’ve got a branch with the interface, default matcher, integration points, and tests if you want to look at concrete changes. It doesn't work yet because I haven't figured out how to get the types to work with Vite, but in theory it should work.

Something like this:

+// lib/router/matcher.ts
+export interface RouteMatcher {
+  readonly name: string;
+  matchPath(pattern, pathname): PathMatch | null;
+  matchRoutes(routes, location, basename?): RouteMatch[] | null;
+}

 // lib/router/utils.ts
+let customMatcher: RouteMatcher | null = null;
+export function setRouteMatcher(m: RouteMatcher | null) { customMatcher = m; }

 export function matchPath(pattern, pathname) {
+  if (customMatcher) return customMatcher.matchPath(pattern, pathname);
   // existing logic...
 }

 export function matchRoutes(routes, location, basename = "/") {
+  if (customMatcher) return customMatcher.matchRoutes(routes, location, basename);
   // existing logic...
 }

https://github.com/dangayle/react-router/tree/feat/pluggable-matcher