@brandonkelly looking forward to this getting released so that I can use the native link field in my new project instead of a plugin. One thing I'd like to surface is that it would be best to be able to get the relative path for internal links, basically anything of the Entry type. I'm using NextJs, and in order for the links to function properly I need to use a relative path for internal links.

<Link href="/about">About</Link>

Is it possible to return the uri?

I've been using Typed Link Field for a few years and the query looks like this:

linkTo {
  url
  text
  type
  element {
    id
    uri
    title
  }
}

Then the Link component in React can switch handle output differently based on type

const Link = ({
  url,
  text,
  element,
  children,
  type,
  className,
}) => {
  if (!url && !element) return null;
  switch (type) {
    case "entry":
      return element ? (
        <RouterLink
          href={`/${element.uri === "__home__" ? "" : element.uri}`}
          className={className}>
          {children || text}
        </RouterLink> : null
      );

    default:
      return (
        <a
          className={className}
          href={url}
          target="_blank"
          rel="noopener noreferrer"
        >
          {children || text}
        </a>
      );
  }
};

Haven't tried Hyper, but they have a linkUri property. I think we'd also need a property for "Open In A New Tab"
Here's a link to the full interface they implemented:
https://verbb.io/craft-plugins/hyper/docs/developers/graphql#the-linkInterface-interface

I don’t see that being necessary. You can extract the URI from the url if you need it.

Thanks for the quick response.

Respectfully, I disagree. It definitely is necessary to have for client side routing to work correctly in a headless application so I see it as a basic requirement that every application needs as far as I know. Yes, you could use a regex or URL object to extract the relative path but it feels wrong to be pushing that operation to the client side – it's inefficient. If the data is already available on the server, why not expose it in the api?

In addition, the target attribute or the value of the "Open in a new tab" lightswitch needs to be added, or that toggle will do nothing in headless apps.

If the data is already available on the server, why not expose it in the api?

It’s not, though. Link fields only know about the full URL. So Craft would be doing the same URL parsing you could be doing.

In addition, the target attribute or the value of the "Open in a new tab" lightswitch needs to be added, or that toggle will do nothing in headless apps.

Sorry, I forgot to include target in the original PR description, but that’s available as well already. Updated the description.

Ok. Thanks for considering.

Hm, why 'uri' is not available?