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.

[aliakbarazizi]

I was in the middle of the migration and saw this, and stopped doing that now my plan is to migrate to another library

this is a huge step back for this library.

[bluepeter]

Just an update that we have been able to successfully migrate to v6. A few code snippets that helped us...

The following 2 code snippets work together:

                <Route path="site/:siteId">                                                                
                  {viewLevel(<Site />, true)}                                                              
                  <Route path="session/:sessionId">                                                        
                    {viewLevel(<Session />, true)}                                                         
                    <Route path="page/:pageId">                                                            
                      {viewLevel(<Page />, true)}         

const viewLevel = (element, modals = false) =>
  !!element && (
    <Route
      element={
        <>
          {element}
          <Outlet />
        </>
      }
    >
      <Route element={null} index />
      {modals && <Route element={null} path=":modal" />}
      {viewerRoutes}
    </Route>
  );

And the following two work together...

<Route element={<TryFixUrl />} path="*" />

const TryFixUrl = () => {
  const path = window.location.pathname.replace(/^\/$/, "");
  return (
    <Navigate
      replace
      to={
        path.endsWith("view")
          ? path.replace(/[^/]+\/([^/]+)/, "$1") + window.location.search
          : "/404"
      }
    />
  );
};

[wintercounter]

You successfully handled 1 specific case from many with an ugly hack. This just validates stronger the concerns many of us have.

…

On Fri, May 20, 2022, 19:20 bluepeter ***@***.***> wrote: Just an update that we have been able to successfully migrate to v6. A few code snippets that helped us... The following 2 code snippets work together: <Route path="site/:siteId"> {viewLevel(<Site />, true)} <Route path="session/:sessionId"> {viewLevel(<Session />, true)} <Route path="page/:pageId"> {viewLevel(<Page />, true)} const viewLevel = (element, modals = false) => !!element && ( <Route element={ <> {element} <Outlet /> </> } > <Route element={null} index /> {modals && <Route element={null} path=":modal" />} {viewerRoutes} </Route> ); And the following two work together... <Route element={<TryFixUrl />} path="*" /> const TryFixUrl = () => { const path = window.location.pathname.replace(/^\/$/, ""); return ( <Navigate replace to={ path.endsWith("view") ? path.replace(/[^/]+\/([^/]+)/, "$1") + window.location.search : "/404" } /> ); }; — Reply to this email directly, view it on GitHub <#8254 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHLJQGF2ACL2L6JCA2PAJ3VK7CU3ANCNFSM5HP3PYKQ> . You are receiving this because you commented.Message ID: ***@***.***>

[GlebAmbrazhevich]

The lack of regex is an issue for brownfield projects with poor URL design. AFAIK if I wanted to mount a param-dependent component on all routes matching /base/(one hundred different URLs)/:myParam, under V6 I'd have to write them all out explicitly, or write the param matching code manually (or just reinstall path-to-regexp and call it with the old regex path).

@tpict Creating a folder structure with unlimited nesting and unique namespaces is a very common thing. Why is it a poor URL design?

[tpict]

@GlebAmbrazhevich I meant in the case that :myParam represents the same resource under all URLs, and the remaining segments were subcategories of that resource. Normally I'd order URL segments from least to most specificity because it's easier to compose URL configurations/views/routers/etc that way... and because that's the way everyone does it! Though I'm not sure this practice is codified anywhere as "URL usability guidelines".

For a folder structure of unknown depth, I imagine the new React Router API works very well since nested relative routes are the crux of the thing.

[jeffersoneagley]

@GlebAmbrazhevich I meant in the case that :myParam represents the same resource under all URLs, and the remaining segments were subcategories of that resource. Normally I'd order URL segments from least to most specificity because it's easier to compose URL configurations/views/routers/etc that way... and because that's the way everyone does it! Though I'm not sure this practice is codified anywhere as "URL usability guidelines".

For a folder structure of unknown depth, I imagine the new React Router API works very well since nested relative routes are the crux of the thing.

I have a similar case where "anything ending in /auth should be shown the auth page"

[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?

[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 /> },
...