Redwood: Route tolerance for trailing slash

[chris-hailstorm]

ENVIRONMENT

$ yarn rw --version
0.0.1-alpha.31

PROBLEM

I'd like both /url and /url/ to match a single route.

Currently, if I use <Route path="/posts" ...> that will match URL /posts but not /posts/. If I change the route to <Route path="/posts/" ...>, it matches /posts/ but not /posts.

When using React-Router, this is easy to solve using a combination of the strict and exact parameters, something like <Route strict={false} exact={true} path="/posts/" ...>.

Is there an option to the Redwood Route object that controls tolerance for trailing slashes?

A regex for path-matching could also be a good approach.

[chris-hailstorm]

I'll answer my own question so others can find it.

A pattern like <Route path="/posts(/?)" accepts 0 or 1 trailing slashes.

This is a standard Javascript regex. Not sure which layer interprets it.

[mojombo]

@chris-hailstorm It's an artifact of the implementation that regex syntax currently works in routes. I expect that will go away so that we can do an optimized parser-based route matcher in the future, but I need to think about it more.

Regarding trailing slashes, we could add a trailingSlashes option on Router that could be one of:

never - Always strip trailing slashes from URLs before matching.
always - Always add trailing slashes to URLs before matching.
preserve - Keep trailing slashes as-is before matching.

Probably we would default to never. Would this solve your use case, or did you have some other requirement in mind?

[chris-hailstorm]

The new / always / don't change approach is very flexible.

I think that would work for anyone -- definitely does for me.

Never as the default is wise --> making canonical is good.

[mojombo]

Cool, I'll get that in and we can see how it feels. Thanks for all the issues you've been filing!

[chris-hailstorm]

YW. Love what y'all are doing. Redwood is checking a lot of boxes.

[chris-hailstorm]

Further reason to not use regex in the way I tried -- although it works (for now) by handling both /path and /path/ in the same route, the regex isn't compatible with the Link element.

E.g. if I create this route:

<Route path="/about(/?)" page={AboutPage} name="about" />

Then later try to reference it as a link by name ...

<Link to={routes.about()}>About</Link>

... when I click on that link, the new URL is http://localhost:8910/about(/?) with the regex expression carried through as a literal in the link-to URL.

Perfectly reasonable behavior. Invalidates my regex approach completely.