More powerful/flexible path matching

[mjackson]

Let's make string-based pattern matching more flexible to accommodate some of the use cases we're starting to see.

In particular, I'd like to propose we follow Sinatra's lead here and:

• Allow ? to mean "match the previous thing 0 or 1 time"
• Modify * to not match . since it can be excluded using ?

By just doing these two changes, we can support the following kinds of URLs:

• /posts/:slug.?:format? (make the .html portion of a URL optional)
• /files/*.* (get the file extension in a separate splat)
• /archive/? (optional trailing slash)

I've already got this functionality in mach and it's working really well. I rarely (read: haven't yet needed to) use a regular expression to match on a URL path. I realize that this discussion will probably evolve to include supporting full-blown regular expressions, but I'd like to discuss that in a separate issue if people are interested.

[bobeagan]

Wouldn't #58 cause your first example to not work as expected? Seems like it make the whole :slug. param optional or did I misunderstand that change?

[mjackson]

@bobeagan Yes, this change would make #58 not work anymore. It's what I was working toward originally when * didn't match . but I didn't get ? implemented in time.

[ryanflorence]

I'm totally 👍 on all of this.

What about path="*" though?

I have one very strong request to maintain and equivalent to what <Route path="*"/> means today. Primary use-case is a NotFound route, but there are certainly others.

Right now you can do this:

<Routes>
  <Route handler={App}>
    <!-- routes -->
  </Route>
  <Route path="*" handler={NotFound}/>
</Routes>

This lets you easily handle routes that aren't found, gives you a chance to redirect when you've changed routes, etc. etc. (#139 (comment))

Why not just use a <Routes defaultHandler={NotFound}/>

We've talked about having a defaultHandler that matches when nothing else does. Implementing that would make it so we don't need an equivalent to the current path="*". My guff with that is that it breaks the nesting paradigm to share UI with the NotFound handler and the other views.

If I have a logged in user, and some route is not found, I still want my application chrome up in the top of the browser--or not, I should be able to do either.

If we simply come up with an upgrade path for path="*" then we can continue to do things like this:

<Routes>
  <Route handler={App}>
    <!-- routes -->
    <!-- NotFound now shares the App UI chrome :D -->
    <Route path="*" handler={NotFound}/>
  </Route>
</Routes>

Proposed upgrade paths for path="*"

<Route path="..."/>
<Route path="**"/>
<Route path={Router.NOT_FOUND}/>
<NotFoundRoute/>
<Route path="*"/> <!-- special case naked *, if no other characters are present -->

[ryanflorence]

doesn't sinatra match anything with *?

[mjackson]

From the Sinatra README:

get '/say/*/to/*' do
  # matches /say/hello/to/world
  params[:splat] # => ["hello", "world"]
end

get '/download/*.*' do
  # matches /download/path/to/file.xml
  params[:splat] # => ["path/to/file", "xml"]
end

The * in Sinatra matches anything up to a ., ?, or /. The implementation details are here.

[ryanflorence]

but doesn't just * mean "match anything else?

http://stackoverflow.com/questions/10806024/how-can-i-give-sinatra-a-catchall-default-route

[mjackson]

Not AFAIK. That SO question was answered by the same guy who asked it in the first place. I doubt the answer is accurate.

[sophiebits]

(FWIW answering questions you've asked is explicitly endorsed by SO.)

[ryanflorence]

okay, well, regardless of what sinatra does, thoughts on supporting the current path="*" use-case with some new API?

[mjackson]

My vote would be to use ... to mean "whatever else is left". It's going to be used in ES6, as well as in a few places in React (I've heard).

Only problem is I guarantee someone is going to try /files/.../name.jpg, which won't work...

Hey, but that actually doesn't look too bad. Maybe instead of altering the behavior of * we just introduce ... which basically means "match anything up to the next ?, /, or .". Hmm...

Hmmm... but the problem with that is that now

/files/*.*

becomes

/files/.......

...

[mjackson]

I guess we could just error if someone tries to use anything after ...

[ryanflorence]

I'm actually laughing out loud about /files/.......

[ryanflorence]

yeah, ... is not a delimiter, its a symbol for catchall. Only restriction is that nobody can have the url .... I'm not sure I want to support that person's use-case anyway.