The <Link /> component treats all URLs as local routing paths

[maranomynet]

If I pass full URLs (say https://www.external.com or mailto:foo@bar.com) to the <Link/> component's to="" prop, those URLs get treated like local routing paths beginning with some weird folder named "https:" or "mailto:[…]".

This means that in each project I have to create a wrapper to handle this.

import React from 'react';
import { Link as RemixLink } from '@remix-run/react';

export const Link = (props) =>
  // Check if the URL starts with a protocol
  // (https:, mailto:, tel:, etc...)
  /^[a-z]+:/.test(props.href) ? (
    <a {...props} />
  ) : (
    <RemixLink to={props.href} {...props} />
  );

Next.js used to have this exact same problem, but they seem to have fixed it, at least as early as in version 11.

(NOTE: This affects all Remix versions i've tried, up to and including v1.8.2)

EDIT:
I understand the intent of the <Link/> component is to handle internal routing magic, but it's still prefectly predictable that users are, more often than not, working with a mixture of local and external URLs, with a few non-HTTP URIs mixed in too.

The workaround is easy (as illustrated above) but feels like bothersome busywork.
Baking this into the <Link/> component seems like such an easy win for Remix.

[machour]

I think @brophdawg11 recently worked on this on the router (unless I'm confusing with redirects?)

[maranomynet]

I updated my post, but this affects v1.8.2

[brophdawg11]

This is currently expected behavior - Link is currently only intended for links within your app, external links need to use an <a href>. I think we're open to changing that though so let's get some upvotes on this proposal!

@machour yeah I think you're thinking about redirect to external URLs, which was done recently.

[sergiodxa]

I think Link should detect external links and avoid client-side navigation, also in Remix ignore prefetch, I personally don't mind the check if (props.href.startsWith("http")) to render an anchor tag myself but I have seen lots of people use only Link even for internal ones.

[mjackson]

sigh ... yeah, we should probably just update <Link> to respect external URLs. Either that or we continue to answer this question until the end of time for people who refuse to use a regular <a> (or just don't know the difference).

Maybe we could warn when someone renders an external link? And say something like "hey, just so you know, you could use a regular <a> here instead of <Link>"...

[brophdawg11]

I find the above is pretty common when a CMS is involved.

In my experience, once apps reach a certain size they end up with some form of <Link> wrapper (for their own styling, analytics, etc.) so it feels like most apps would have a place to put this a/Link fork in practice. But it does come up as a question quite often 😕

[sergiodxa]

it feels like most apps would have a place to put this a/Link fork in practice

Yeah I have my custom Link that checks the internal/external href to know what to render, I imagine most people don't want to do that 🤷

[maranomynet]

The Nextjs devs went through the same thought processs some time back.
"next/link should be pure. Internal routing only." etc.
Their eventual conclusion was to add this feature.

It's cheap (wrt performance and bundle size), without obvious "slippery slope" risks.
It helps with real and common use cases.
It removes a class of runtime bugs where a non-local URL slips into a <Link/> by accident.
It reduces the time users spend scratching their heads when <Link/> breaks their initial expecation model.

[maranomynet]

What do folks think is happening with a <Link to> vs. <a href>? Do they know about client side navigation vs. document navigation?

I think people (even those with deep knowlege of pushState, etc.) would like to spend as little time as possible pondering the intricacies of routing mechanics. That's what Remix/RR is for, no?
I think folks expect a <Link/> to create a link that A) works B) picks the best routing strategy for a given URL, as far as that's possible.

[sergiodxa]

I also think the router could do it better than just checking if the to point to an external or internal link, since Link has access to the router internals it could check if the to resolves to an actual route or not, and if it doesn't (external routes or invalid routes) work as normal anchor.

This would also mean if the route doesn't exists the page will reload and the user will get a 404 response.

[andrelandgraf]

I wrote myself a small package (remix-isomorphic-link) when I ran into the same issue. I agree that a wrapper is necessary in some cases (like parsing markdown at runtime where you have both internal and external links).

[jenseng]

Until Remix supports external URLs in <Link to>, you can use eslint-plugin-remix-react-routes' no-urls rule to detect/prevent most (currently) incorrect usage (i.e. strings that can be resolved statically).

[maranomynet]

Update: This feature has landed in v1.12
https://github.com/remix-run/remix/blob/main/packages/remix-react/CHANGELOG.md#1120