Feature request: Normalize trailing slashed by default

[chaance]

See #4841 for context.

Many users have expressed concern that useRouteMatch returns the trailing slash in matching URLs, which makes joining them with path segments unpredictable in some cases.

#4841 shows several examples of current workarounds. Opening this discussion to explore various ways we might be able to make this simpler/more predictable and consistent in v6.

[ryanflorence]

React Router doesn't care about trailing slashes in matching, so I would expect useRouteMatch to either

1. return a trailing slash only if it was given a trailing slash
2. never return with a trailing slash.

But if it always returns a trailing slash I'd like to change to one of the above.

[chaance]

Currently it's # 1, which I think is correct. I think what some folks are asking for is # 2.

[mjackson]

The way it works currently in v5 is useRouteMatch returns an object like this:

{
  path: "", // the path we used to match the URL
  url: "", // the portion of the URL pathname that was matched
  isExact: bool, // whether or not we matched exactly (the entire URL was consumed)
  params: {} // the URL params
}

If they designed their site to use trailing slashes in their URLs, then match.url will include a trailing slash. If they are not using trailing slashes on their site, then match.url will not include a trailing slash. But in both cases, we are just giving them the portion of the URL pathname that was matched.

The problem here is that people don't/can't redirect URLs that end with / to their non-/ equivalents on the server side, or vice versa. So when React Router kicks in on the client, they don't know if the current URL ends with a / or not. So they have to create a normalization function that adds/removes trailing slashes depending on what they want to do with match.url.

Aside: using a client-side <Redirect> to "fix" this problem (as some have suggested in #4841) looks like it works, but in reality your SEO juice is still split between the / and non-/ versions of that same page since you served up HTML at both of them. So this isn't really a great solution.

The best solution to this problem is for users to a) decide which URL structure they want to use throughout their site (either with trailing / or without) and then b) redirect accordingly on the server side. Then on the client side they would always know whether the current URL ends with a trailing / or not, and so they'd know if match.url has a trailing slash. Redirecting on the server side also has the nice benefit of preventing search engines from indexing the redirected URL, so your SEO juice is concentrated on one URL (good) instead of two. Most hosting providers give you a config option that allows you to configure trailing slash behavior, so this should be a pretty easy fix for most users. This should be the majority of users.

For people who can't redirect on the server for some reason, they should probably just strip the trailing slash before joining with another string. We could maybe provide a function like:

function joinUrls(a: string, b: string): string {
  return a.replace(/\/+$/, "") + b.replace(/^\/*/, "/");
}

<Link to={joinUrls(match.url, "some/path")}>some path</Link>

What should we do in v5?

If we change what match.url returns in v5 it'll break a bunch of apps. If we tell them to take control over their trailing slashes and do a server-side redirect they'll probably say that either a) they can't for some reason or b) the match.url at the root is always going to be /, regardless of whether they are using trailing slashes or not so they still need joinUrls in that case.

My vote would be to provide the joinUrls function above, and then they can use that anywhere they need to join something with match.url.

We should also add something to the documentation that says they should be stripping/adding the trailing slash in a server-side redirect for the sake of SEO.

What should we do in v6?

In v6 useMatch returns an object like this:

{
  path: "", // the route path that was used to match
  pathname: "", // the portion of the URL pathname that was matched
  params: {} // the URL params that were matched
}

We should probably change match.pathname to match.url for parity with v5, and then just always strip the trailing slash so people don't need joinUrls. Instead, they can just use a template string literal:

<Link to={`${match.url}/some/path`}>some path</Link>

The only thing we lose if we make this change is you won't be able to determine if the current URL ends with a trailing slash, but I doubt many people are going to need that. They mostly just want match.url for building nested <Link>s.

We should also add a note in the v6 docs about configuring your server to add/remove the trailing slash in a redirect for the sake of SEO. This is not router-specific (i.e. they don't need to in order to use React Router), but it's just good practice.

[mjackson]

Quick update: @chaance and I had a chat about this and we decided it's best to use the following shape in v6 for useMatch:

{
  params: {}, // the URL params that were matched
  pathname: '...', // the portion of the URL pathname that was matched
  pattern: { path: '...', caseSensitive: bool, end: bool } // the route path/pattern that was used to match
}

This is the same shape as objects returned from matchPath in v6.

The match.pathname will include the trailing slash as it appears in the current URL. We recommend people create a function to join URLs if they need one for creating e.g. nested links.

[philcunliffe]

Site and app owners cannot fully "take control" of trailing slash patterns without redirecting because anyone linking to our site or just typing in the url can add a trailing slash. The V5 documentation explicitly calls out that the url component returned from useRouteMatch is "useful for building nested Links", but doesn't mention at all that a trailing slash could be present.

Unless the route is matched using the "exact" option to a route with a trailing slash it seems unintuitive that the "portion of the URL that was matched" would include it.

If the current state must be maintained then the documentation should be updated to mention it with an example of how to mitigate. In its current state it's very unintuitive and a lot of users are likely ruining their SEO with redirects because of it.