[Feature]: 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