Domain-level links should not be redirects

[markomitranic]

I was using the domains configuration option and it works like a charm. There is one thing I dislike about it tho - the links that Link generates lead to the current domain, and then we get redirected to the different domain.

(In the following examples, i am on http://example.com/)

It is quite interesting that Link always creates relative links, which then perform redirects:

<a href="/en-GB">en-GB</a>
<a href="/">da-DK</a>
<a href="/en-DK">en-DK</a>

While response headers are perfectly able to generate absolute URLs:

Link:
<http://example.co.uk/>; rel="alternate"; hreflang="en-GB", 
<http://example.com/>; rel="alternate"; hreflang="da-DK", 
<http://example.com/en-DK>; rel="alternate"; hreflang="en-DK"

Ideally what I believe Link should result in, in this situation, is:

<a href="http://example.co.uk">en-GB</a>
<a href="/">da-DK</a>
<a href="/en-DK">en-DK</a>

I suggest that we fix this in a future release. I'd be interested in making a PR - if this is something that sounds correct to you.

Update: fixed a typo.

[amannn]

Thanks for the feature proposal!

I think this is closely related to #444. As there can be multiple domains that serve the same locale, I think the user should supply an explicit domain in this case, also removing any ambiguity.

Accepting domain both in the navigation factory functions as well as the generated APIs is being tracked in #444.

I'd be interested in making a PR - if this is something that sounds correct to you.

If you're interested, absolutely! I think the changes discussed in #444 are quite closely related and might need to be implemented in one go to ensure they fit together. The change might be a bit more involved, but if you're up for the challenge I'd be happy to help where I can!

The discussed APIs would require a major version, there's also some work necessary on my end to see if we want to incorporate other changes while we're making a breaking change.

[markomitranic]

Ah yes, the same-locale-multiple-domains use case complicates things. I see it as a severe edge case, but if it is something we must support then the interface does become messier.

On the surface this seemed like a smaller issue, as we already successfully do this inside Link headers. I'll read through #444 thoroughly before continuing.

[markomitranic]

@amannn Just wanted to give a slight update on this, for future readers :)
next-intl doesn't export an unified function that allows us to resolve URLs, the closest to that is Link component, but it suffers from:

1. Being a component, not a function, and thus not returning a string.
2. Being a bit unambiguous about client/server side, as it uses useEffect and useMemo at various points.
3. Not returning absolute urls when appropriate.

Thankfully, the logic behind it is not that complex at all, it is just a bit nested. I don't see something like this is likely to be merged anytime soon due to a lot of other features that next-intl has to support (and I don't have to), so I rewrote it locally, as a plain server-only function resolveUrl, that supports all three of the abovementioned issues.

/**
 * Helps resolve an actual URL, based on a path name.
 *
 * Similar to `getPathname` and based on it, but expanded
 * with ability to add prefixes and domain names to external links.
 * Understands the difference between internal and external link.
 *
 * @see {@link getPathname}
 * @example
 * resolveUrl({ href: "/test", locale: "da-DK" }, "da-DK")
 * "/test"
 *
 * resolveUrl({ href: "/test", locale: "en-DK" }, "da-DK")
 * "/en/test"
 *
 * resolveUrl({ href: "/test", locale: "en-GB" }, "da-DK")
 * "https://wineandbarrels.co.uk/test"
 */
export default function resolveUrl(
  params: Parameters<typeof getPathname>[0],
  currentLocale: Locale,
) {
  const targetLocale = params.locale ?? currentLocale;
  const targetDomain = getDomainFromLocale(targetLocale);
  const currentDomain = getDomainFromLocale(currentLocale);

  const isCurrentDomain = targetDomain.domain === currentDomain.domain;
  const isDefaultLocale = targetDomain.defaultLocale === params.locale;
  const languageCode = targetLocale.split("-")[0];

  let urlBase = "";
  if (!isCurrentDomain) urlBase += `https://${targetDomain.domain}`;
  if (!isDefaultLocale) urlBase += "/" + languageCode;
  const pathname = getPathname({ ...params, locale: targetLocale });

  return {
    href: urlBase + pathname,
    locale: params.locale ?? currentLocale,
    type: isCurrentDomain ? "relative" : "absolute",
    changedLocale: currentLocale !== params.locale,
  };
}

function getDomainFromLocale(locale: Locale) {
  const definiton = intlConfig.domains?.find((definition) =>
    definition.locales?.includes(locale),
  );

  if (definiton) return definiton;
  throw Error("Provided locale matches no domains");
}

The point of all this was to get a central, unified resolveUrl function that is (almost)pure and entirely detached from react. Then we can freely use it in various links, headers, redirects and whatnot else.

This nice little function can now be safely used in some Link components that wrap it and provide it with the data. Here is a server-only link component example, this is what we'd use most of the time:

type Props = Omit<ComponentProps<typeof NextLink>, "href" | "locale"> & {
  href: Parameters<typeof resolveUrl>[0]["href"];
  locale?: Locale;
};

export default async function Link(props: Props) {
  const currentLocale = await getLocale();
  if (!isLocale(currentLocale)) throw Error("Invalid current locale given");

  const { href, locale, changedLocale } = resolveUrl(
    {
      locale: props.locale ?? currentLocale,
      href: props.href,
    },
    currentLocale,
  );

  return (
    <NextLink
      {...props}
      href={href}
      hrefLang={changedLocale ? locale : undefined}
    />
  );
}

Sometimes we need a client version of this component, and the client the component is quite literally the same, the only difference being use of useLocale instead of await getLocale.