Fix <Link to="string">

[pshrmn]

New implementation will parse the string to create an actual location object. This also means that a to string with no pathname will resolve using the current location.

The href value is also now stored in state, only recalculating it when the to prop changes.

Edit: If anyone is looking at this, but hasn't read through #5488, the reason for this PR is that when a user renders a <Link> whose string to does not include a pathname, the rendered anchor's href does not include a pathname (<Link to='?test=ing'>Test</Link> -> <a href='?test=ing'>Test</a>). This results in conflicts with the output of the <StaticRouter> since that explicitly makes hrefs absolute paths by enforcing that the string begins with a forward slash. Since React Router works with location's whose pathnames are absolute, I felt it was more appropriate for the <Link> to produce absolute URLs than it was for the <StaticRouter> to have a special use case.

[timdorr]

Why not keep things inside the render? Does createLocation have some sort of side effect?

[pshrmn]

We could have the funcionality in render, but with string to props, that would mean that we re-parse the string every render. Using state also saves us from calling createHref every render. This isn't a huge performance win, but I'm not aware of any negative effects this would cause either.

[mxstbr]

Would love to see this land! 😊

[mjackson]

I'd definitely like to keep the create call inside render. If it's a perf problem we can use sCU, but I'd like to see some proof that perf is bad before we make that optimization.

[pshrmn]

I reverted to computing the href in render.

[timdorr]

I think this is good too. In she goes...

[mxstbr]

YAS 🎉 Was this released?

[manjufy]

This change causing the href calculations to be
http://abc.com/http://abc.com/contact.html
After upgrading to never version, href calculation seems to be messed up

[pshrmn]

@manju16832003 Can you provide sample code (or ideally a sandbox) to reproduce the error?

[manjufy]

<Link to="http://abc.com/ContactList.html"></Link>
This is how I used it before and used to work, however, after upgrading it to new version, it broke :-).

[pshrmn]

@manju16832003 You should only be including the pathname (and optionally search/hash) for a location, not the scheme or domain.

<Link to="/ContactList.html">Contact List</Link>

[Android3000]

@pshrmn Interesting. We ran into the same thing as @manju16832003 too. I guess I never picked up in the documentation that Link couldn't handle external links (which up until this point, it could). Maybe this could be made more explicit in the documentation?

While obviously Link is intended for internal navigation, I'm sure there are other users who may be running into similar things too -- I could easily see a use case impacted by this in a breaking way, like say a re-usable component with a Link inside that sometimes may be provided an internal URL, and sometimes an external URL. Easy enough to fix if one is aware, but something I could see coming up as a surprise for some folks.

Either way, thanks for the updates!

[Skandar-Ln]

Suppose the location path is /task/list，I have a Link
<Link to="task/detail/xxx" target="_blank">detail</Link>
before this pr，click the link we get the new window of path task/detail/xxx，but after it，I get /task/list/task/detail/xxx，So, it's a bug。Did you think of it before？

[pshrmn]

@Skandar-Ln you are using a relative pathname (no leading slash), so the pathname is being appended to the current location's pathname.

[noahm]

I just wanted to point out that like @manjufy, we were using the component more or less universally and this is a breaking change. I also agree with @Android3000: the release notes for 4.3.0 should definitely be clear about this change along with a note the general docs.