RFC: Relative Links and Routes

[ryanflorence]

We intend to ship Relative Routes and Relative Links soon. I'd like to hear people's comments on something I'm not totally sure about yet.

What are Relative Links and Routes?

Instead of <Route path={match.path + '/more/stuff'}/> you could simply do <Route path="more/stuff"/> and Router will use the lack of / at the start of your path as a hint that you want to just use whatever path is above you. Relative!

Same with links. Instead of <Link to={match.url + '/more/stuff'}/> you can just do <Link to="more/stuff"/>.

The Problem

Going "down" as shown in the quick example up there is easy. But we're not sure what ".." should mean. There are two options for what it means: go up a URL segment, or go up a matched route.

Go up a URL segment

With plain anchors tags, .. means "up a URL segment". Given the following URL, an anchor tag with the following HREFs results in the following URLs:

/clients/invoice/123

href	url
payments	/clients/invoice/123/payments
	/clients/invoice/123
.	/clients/invoice/123
..	/clients/invoice
../	/clients/invoice
../..	/clients
../../	/clients

(As far as I can tell, feel free to double check!)

So I think everybody's intuition around this is to just do exactly that and be done with it. Ship it.

However, I have this gut instinct that our intuition right now might be keeping us from a better meaning of ".." in a React Router app?

Go up a matched Route

Maybe your app is something like this:

  <Switch>
    <Route exact path="/" component={Home}/>
    <Route path="/clients" render={() => (
      <Clients>
        <Switch>
          <Route exact path="." component={ClientList}/>
          <Route path="invoice/:invoiceId" component={Invoice}/>
        </Switch>
      </Clients>
    )}/>
  </Switch>

Maybe we want ".." to mean "go up a matched route" rather than "go up some url segments".

So now the "relative" portion of the Link's to prop is the parent Route's path, not the current location.

to prop	link's url
..	/clients
../..	/

Notice .. doesn't go to "invoice" because that's not a route that will ever match.

Pros

• When you change a parent Route's path prop, the relative links below don't need to be updated
• You can't link to something that doesn't have UI (probably, see cons*)

Cons

• *Since any ol' route can match a location w/o a relationship with other Route's that match, a Link in one place can potentially have a completely different href than a link somewhere else--even though they have the same to prop 😬. It all depends on the Route's path the Link is rendered within.
• It's against most people's intuition

What do you think?

[davidascher]

I think the expected behavior is better because expected with that syntax. The route walking behavior could be useful but I'd suggest looking for another syntax.

[ryanflorence]

Ah so maybe <Link to="../projects"/> works on URL segments and <Link to="^^/projects"/> could work on the parent route's path. Interesting.

Not excited about inventing syntax though.

[alanhussey]

What about a separate prop that is mutually exclusive with to? Something like <Link upOneRoute>? Then you can avoid overloading the API. (another option: <Link up={count}>, to traverse more than one level)

[1000hz]

I think going up a matched route would be a bad idea. 2 reasons I can think of off the top of my head:

Notice .. doesn't go to "invoice" because that's not a route that will ever match.

1. I don't think you can make this claim when routes in v4 can be anywhere in the component tree.

2. What happens when you decide to add a <Route path="invoice" /> a few weeks later? Now you've inadvertently borked all your relative links.

[BTMPL]

I think your assumption in first post is wrong, @ryanflorence

Given URL like /clients/invoice/123 the behavior is:

href	url
payments	/clients/invoice/payments
(empty href attribute)	/clients/invoice/123
.	/clients/invoice
..	/clients
../..	/

[pshrmn]

@BTMPL Resolving here is going to be slightly different than how the browser treats hrefs. Before stripping the last segment, we ensure that the pathname ends in a trailing slash. That way only an empty string is stripped and we can treat /clients/invoice/123 the same as /clients/invoice/123/ (we get the segments ['clients', 'invoice', '123']).

The only tricky thing with that is that we have to keep track of if the original path had a trailing slash. I dealt with that in #4459 with this code and these tests (which I think are correct, but I haven't reviewed them in a couple months).

[BTMPL]

@pshrmn I understand that this is a decision aimed at new developers that might be unfamiliar with the URI syntax, but that's a step away from the specs.

Also, Ryan's example was based on anchor tags, so I assumed spec compliant, not react-router variant and should follow the RFS - https://tools.ietf.org/html/rfc1808#section-5

Is there a real need for relative links other than not having to access props.match.url ?

[mcrawshaw]

The composability of React and RR4 are great. I think when @ryanflorence mentions the second option he is targeting 1st class support for this concept. Allowing a component to ignore implementation details of its owner/parent, etc.

Conceptually, I think it's useful to classify path segments in 2 seperate ways. Navigation and parameter. An example /list/page2/item1/tab2. For the sake of discussion, list and item1 are probably navigation segments (resulting in route matches and a rendered component), and page2 and tab2 are parameter segments (passed to the matching component). I argue that navigation segments are often what we want to work with when discussion relative paths. Parameter segments are often optional and can cause headaches.

I'm not sure what the exact solution is, but my most common needs are as follows:

• Navigate down the tree, easy in any method, just append path to the existing one. This is already possible with match.url, if a little verbose.
• Navigate up the tree, almost always I want to go the parent match, never up one segment (possibly an parameter segment). Option 1 sounds great, until you try to deal with optional parameter segments. Think of trying to go up the tree from /list (page1 is the default) vs /list/page2. There is currently no support for this in RR4.
• Change parameter segments the same position in the navigation tree (i.e. component match). Without getting the parent involved (e.g. send a rootPath prop) we need reference to a base match without parameter segments. For example to="./page2" would always go to /list/page2 regardless if coming from /list or /list/page1. We can reconstruct a new path with only knowledge of the current components domain. There is currently no support for this in RR4.

I believe this description keeps cohesion within the component.

The unfortunate thing about this discussion is that you might have a completely different view if you use RR4 differently within your app. But hoping this makes sense to as most people as possible.

[thomasvm]

In my head <Link to="" /> directly corresponds to <a href="" />, so I would the expect the to prop to behave in the same way as the a's href. If a relative link behaves differently in react-router than the html counterpart, then that is something and you'll probably will be explaining over and over and over again.

Could the alternative behaviour be implemented in a dedicated component?

[mcrawshaw]

I agree @thomasvm, except for needing a separate component.

Especially with .. as it has such an intuitive use (remove a single segment from the current url). Changing it would require massive userland instruction.

I don't believe . has the same familiarity.

I think @davidascher suggestion is worth considering.

[pshrmn]

Relative links would be completely for convenience (i.e. not having to use match.url and string concatenation).

I think that as long as the resolving behavior is well documented, I'm okay with being slightly different from how anchors resolve. The current URI spec seems mostly inspired by static file servers, where trailing slashes are normal (e.g. /somewhere/ is really /somewhere/index.html). When they aren't, linking to child pages is annoying.

<!--
for example, with window.location.pathname = '/user/123',
you have to include the user id in a relative link
-->
<a href='123/edit'>Edit</a>

If we automatically insert a trailing slash, then we get the behavior that I feel like the resolving was originally built around. Maybe I'm just assuming that intention because it fits my argument, but RFC 1808 was written over 20 years ago.

Also, while this behavior is different from how anchors resolve, it is consistent with how the terminal apears to resolve with cd (they may be appending the trailing slash, but visually the terminal does not show it).

~/code $ cd forks
~/code/forks $ ls
react-router history
~/code/forks $ cd react-router
~/code/forks/react-router $ cd ../history
~/code/forks/history $

Anyways, I'm more of a fan of the segment-wise double dot resolving because it is more predictable. I can certainly see the appeal to match based resolving, but I feel like that might lead to weird edge cases.

[BTMPL]

I would be a fan of this solution if react-router would enforce traling slashes but I don't think enforcing anything like that is what the devs want. Maybe adding a separate link component or a prop on the link component to change it to relative mode is the solution?

Maybe I'm just assuming that intention because it fits my argument, but RFC 1808 was written over 20 years ago.

Sure, but it's still in use today, and a lot of webdevs are used to how it works ;)

[lewisdiamond]

@ryanflorence
Given /clients/invoice/123, a link to payments should definitely go to /clients/invoice/payments, not what is suggested in the first post.
@BTMPL
Given /clients/invoice/123, . should not go to /clients/invoice but rather /clients/invoice/ (trailing slash, same goes for your .. example)

Why not follow standards?

[binki]

I came to this bug researching how to write relative <Route/> with react-router because I don’t get how nesting would make sense without support for relative routes. I was surprised that this is not a feature yet.

Maybe links could just not support ... If you’re trying to navigate to a different page in the app which requires going up, that means your <Link/> implies it knows the structure of its parent components. Requiring components to know where they will be called from seems to work against the ideal react components data flow.

By disallowing .., you could encourage in the docs for authors to pass down absolute link generators which may themselves be built from relative contexts. For example, a demonstration of a component knowing only about <Routes/> it manages and passing the necessary information to other components which might want to link to routes it manages:

<Route path='a/:aParam1/:aParam2' render={routeProps => <SubComponentA aParam1={routeProps.match.params.aParam1} aParam2={routeProps.match.params.aParam2}/>}/>
<Route path='b' render={routeProps => <SubComponentB buildALink={(aParam1, aParam2) => routeProps.match.url + '/' + ['a', aParam1, aParam2].map(encodeURIComponent).join('/')}/>}>

I think this sort of pattern enables you to write components that can use <Route/> without knowing about the structure of any components containing them. If you change any <Route/> in this component, you can immediately see all dependencies on that <Route/> and fix your link builders from one spot. This pattern is not enforced if the concept of .. is supported by relative <Link/>s because developers will take that shortcut.

Sorry if this isn’t coherent or isn’t quite on topic. My demo also probably uses react-router incorrectly.

P.S., I also find it confusing that baseUrl=/clients/invoice/123 with url=payments resolves to /clients/invoice/123/payments. Everyone expects browser/standard URI behavior such as is supported by all the URI libraries out there:

> require('url').resolve('/clients/invoice/123', 'payments')
'/clients/invoice/payments'
> require('url').resolve('/clients/invoice/123/', 'payments')
'/clients/invoice/123/payments'

However, route-relative URI support for <Link/> needs to be supported somehow for the feature to be useful. I’d like if a relative <Link/> were to always be relative to the full matched route plus a /. As long as the documentation for relative <Link/> clearly states that it is relative to matched route plus /, I think that it won’t be too confusing. That way it would match the behavior of relative <Route/>, making it easy to build links to relative <Route/>. Just don’t tell people that relative <Link/> it is relative to the URI they see in their browser, say there’s an implicit / and ensure it’s easy to get the version of the URI with that implicit / from the match object that, e.g., includes optional parameters (by just placing extra consecutive /) if there isn’t already an API for that (match.url does not do this, so it is unusable for building relative links).