Add ** splat that matches path separators

[tamorim]

Hi!

I have an application which needs to route an unknown number of categories.
I use the route like this: /*/c.
But, there's some problem in the matching, because if I have a path like this: /you/are/cool/c.
He prints the warning of the title of this issue on the console.
But like this: /you/are/okay/c works fine.

This is due to the non-greedy nature of the splat param?
Is there any way to get around it or to fix this?

[timdorr]

Can you post your route config that triggers this?

[tamorim]

I think if you try this you may trigger the issue:

<Router>
  <Route path="/*/c" component={CategoryPage} />
</Router>

[mjackson]

No, we currently don't have the notion of a greedy splat character.

You could possibly work around this problem by using /*/c* and capturing everything that comes after the first c in your second splat. If there is more than one splat in a path, you'll get an array as the value of the splat param. So, at /you/are/cool/c your params should be { splat: [ 'you/are', 'ool/c' ] }. At /you/are/okay/c your params should be { splat: 'you/are/cool' }. It's not pretty, but it could work for this special case.

In the future, maybe we use ** and * to distinguish between a greedy and non-greedy splat, kind of like glob does, so you could do stuff like this:

/*/c matches /you/are/okay/c
/*/c does not match /you/are/cool/c
/**/c matches /you/are/cool/c

Dunno. Just an idea.

[mjackson]

Just to be clear, the problem lies when the category starts with c

@tamorim Yes, I understand. In the workaround I proposed you would need to check if params.splat is an array. If so, you'll know that params.splat[1] ends with /c. So you can join params.splat together like:

var splat = params.splat

if (Array.isArray(splat)) {
  var joined = splat.join('/c')
  splat = joined.substring(0, joined.length - 2)
}

[taion]

IMO this ties in a bit to #52, #759 (comment), and #2215 (comment) with wanting a way to more richly specify how to match route parameters.

I really like the way Flask does it, but as a Flask user I might be a bit biased. Also most likely with ES6 template strings you can probably do better. But e.g. with something Flask-y you'd set up this rule as /<path:foo>/c.

[tamorim]

@mjackson I deleted the comment that you quoted as soon as I saw your first answer!

I'm interested in helping and make this feature possible. Is it alright or it's not on scope for now?
We can discuss how to work this out.

[timdorr]

In the future, maybe we use ** and * to distinguish between a greedy and non-greedy splat, kind of like glob does.

I happen to like that a lot. Plus, it shouldn't be too hard to implement. You just add here and adjust the regex above. And write tests, of course 😄

[mjackson]

@tamorim No worries! I just quoted it for context.

@timdorr You're right. Shouldn't be too difficult to add at all. I'd be happy to review a PR if you or @tamorim would like to take a shot at it.

@taion The approach I've been taking so far with our pattern matching is "put a new feature in when someone can't do something". Granted, on the surface it seems like it should be pretty easy to find a standalone library to do what we need here, but it's tricky because we need to be able to do the inverse as well. i.e. we don't just parse paths, but we (used to) create them too. If we ever bring back route names, we'll need that capability.

[taion]

@mjackson

Sure - what I mean is that Flask/Werkzeug offer an example of a good abstraction of pluggable pattern matching (via a mini-DSL) that has worked pretty well for me. The way it looks like is that instead of e.g. our

/a/:foo/b

The preferred syntax for specifying a URL rule looks like e.g.

/a/<foo>/b

This is extensible to allow people to do things like

/a/<str(length=2):foo>/b
/a/<int:foo>/b
/a/<path:foo>/b
/a/<uuid:foo>/b
/a/<my_custom_rule:foo>/b

str, int and path are built-in (in this case the URL rules handle both matching and converting params), while my_custom_rule is an example of the syntax for using a custom URL matching rule. Per the str(length=2) example these converters can also take arguments.

These rules are used to both match and generate URLs.

The nice thing about something like this sort of general solution (not necessarily in this exact syntax form) is that they'd let users solve their own problems, while still keeping the same workflow around route matching, instead of adding something like next() from Express.

ETA: Werkzeug docs are here: http://werkzeug.pocoo.org/docs/0.10/routing/

[taion]

The <int:foo> case is one decent motivation for having something like this BTW - I've found it a nice convenience to have my URL routing framework just 404 anything that doesn't match the pattern I want before it even gets to my URL handler, and if I'm specifying that it's an integer in the URL rule, I may as well also have the routing convert that parameter to the right type (rather than just a string).

Also I forgot to say, but the difference between str and path above is that path is like the ** glob in that it also matches /s as needed.

[timdorr]

@taion I think that's getting off topic a bit with this issue. This is just about the greediness of splats. Maybe reopen #52 and get the conversation going there?

[taion]

Ah crud that's PR instead of an issue. I'll open a new issue.

[taion]

Sure - I guess the point I wanted to make is that a greedy splat is more or less the same as a URL parameter that matches a path rather than just a string. I think "greedy splat" (or splats at all really) necessarily needs to be a first-class concept; everything can just be a special kind of URL param.

[knowbody]

shouldn't this issue be closed?