Resolve relative paths

[pshrmn]

I know that @ryanflorence has mentioned some work on relative URLs in other threads, but I thought that I'd make a pull request with a possible working option based on RFC 1808.

I left in comments so that hopefully it should be understandable, but you might also need to reference the RFC 1808 steps. It passes the tests described by 1808, albeit with one modification:

In 1808, anything after the final forward slash in the base url is removed before resolving URLs. However, in React Router, the content after the final forward slash is the base for its children, so it should not be stripped. The tests have been updated to reflect this.

Note: I'm exporting the makeRootRelative function because it was convenient while I was writing this, but the tests for it should just be folded into the createRouterPath tests.

Currently the only tests are the examples from the RFC, so those will probably need to be expanded to ensure correctness, but hopefully this can be a good starting point for addressing the issue (mostly because I dislike writing to={`${pathname}/bar`}).

[pshrmn]

I had to reset this because the 'hashType noslash' tests are run after the 'hashType hashbang' tests, at which point the hash is #!/, which breaks the 'adds a hash link' test because it uses a relative URL and would become #!/foo instead of #foo.

[timdorr]

Why not make this 3rd arg optional, with a default to ''? Less code changes elsewhere that way.

[pshrmn]

I think that this is at a decent place right now.

The main interaction is done through a resolveLocation function. It takes a location (either a string or a location descriptor) and a base string, which is the absolute pathname to resolve with. If the base string is not provided, it will end up using / as the base.

<Link> and <Redirect> components resolve their to props based on their match parent.

This doesn't try to automatically resolve locations when a user is manually navigating. In order to do that, the resolveLocation function should be exported and the user would just need to resolve based on the pathname of the match that they are in:

import { resolveLocation } from 'react-router'

class MyComponent extends React.Component {
  back(loc) {
    const { match, router } = this.context
    const base = match && match.parent && match.parent.pathname
    router.transitionTo(resolveLocation('..', base))
  }
}

(I'm not actually exporting it in the lastest PR, but that's a simple fix)

[pshrmn]

Rebased for the latest version. The new match context is a bit annoying to work with, but everything checks out.

[thevangelist]

When's this coming in?

[mjackson]

I'm afraid this PR is a bit oudated, but I'd like to explain how we're handling relative <Route>s and <Link>s in v4 using the match object.

Relative <Route>s can use the match.path to get the accumulated <Route path> at the position they are rendered:

<Route path="/users/:id" render={({ match }) => (
  <div>
    <Route path={`${match.path}/profile`} component={UserProfile}/>
  </div>
)}/>

Relative <Link>s can use the match.url to get the portion of the URL that matched at the position they are rendered:

<Route path="/users/:id" render={({ match }) => (
  <div>
    <Link to={`${match.url}/profile`}>user profile</Link>
  </div>
)}/>

Thanks for taking the time to contribute :) Please take another look at v4. We're pushing for a beta this week.

[sgoll]

@mjackson I think one main use-case for relative paths would be to use .. for going up one level in the hierarchy. Can you do that with relative <Link>s in v4? The last time I checked this was not yet possible.

[mjackson]

@sgoll Yes, you should be able to use relative <Link to> in v4. It's actually the history library's job to do that, where we're using the resolve-pathname module to resolve relative locations. So, e.g. if you history.push('../foo') it will do the right thing.

You will also probably be interested in the discussion going on in #4332 (comment)