Is there anyway to handle an optional trailing`/` in route path without using `*`?

I have this routes definition

const routes = {
    '/foo': () => <Foo />,
    '/bar': () => <Bar />,
    '/qux': () => <Qux />,
    '/qux/:quxId': ({ quxId }) => <Bar quxId={quxId}/>,
};

As you can see there is a special case when 'qux/:quxId' routes to a different view than '/qux' (In fact it routes to the view for '/bar').

I want to be able to handle any of the routes also being visited with a trailing / (for example '/foo/').

I can get it to work with * but it has a couple of downsides.

1. Because * can match anything, not just the trailing /, routes are able to be activated with an invalid path (/foot for instance)
2. It depends on ordering '/qux/:quxId' before '/qux' so that the * doesn’t clobber the more specific path. This feels pretty fragile, especially because routes is an object, not an array.

The other alternative I can see is to define 2 paths for each route, one with the slash and one without.

const routes = {
    '/foo': () => <Foo />,
    '/foo/': () => <Foo />,
    '/bar': () => <Bar />,
    '/bar/': () => <Bar />,
    '/qux': () => <Qux />,
    '/qux/': () => <Qux />,
    '/qux/:quxId': ({ quxId }) => <Bar quxId={quxId}/>,
};

Obviously that is not very appealing

Is there any other way to address this special case of optionally allowing a trailing slash, or is it something you would consider adding?

Thanks as always 👍

[micmcg]

Yeah I think if the solution was to do '/about/?' you would need to expose the fact that the path matcher is a regex in your API which probably creates maintenance headaches for you.

I think it’s the kind of thing you would want to apply to all your paths if you want it (I know that would be the case for us), so an option for useRoutes would be easier than anything that has to be done per route definition IMO.

So that’s a vote for a matchTrailingSlashes option

[kyeotic]

@micmcg added option matchTrailingSlash published under 0.5.5