TypeScript errors with Content Relationship fields

Hello,

I am encountering several TypeScript errors when using a Content Relationship field in one of my slices. In my "FeaturedArticle" slice, I have a Content Relationship field named article.

Even though the data is present in the object at runtime, I am hitting the following errors:

  1. When I try to access top-level document properties: const { first_publication_date, lang } = slice.primary.article; i get this error
Property 'first_publication_date' does not exist on type 'FilledContentRelationshipField<"article", string, PickContentRelationshipFieldData<{ id: "article"; fields: ["title", "image", "excerpt", { id: "categories"; fields: [{ id: "category"; customtypes: [{ id: "category"; fields: ["name", "color"]; }]; fields: [...]; }]; }, { ...; }]; }, Simplify<...>, string>>'.`
  1. Also, when I try to use the field with the PrismicNextLink component: <PrismicNextLink document={primary.article}>, I get this error:
Type 'FilledContentRelationshipField<"article", string, PickContentRelationshipFieldData<{ id: "article"; fields: ["title", "image", "excerpt", { id: "categories"; fields: [{ id: "category"; customtypes: [{ id: "category"; fields: ["name", "color"]; }]; fields: [...]; }]; }, { ...; }]; }, Simplify<...>, string>>' is missing the following properties from type 'PrismicDocument<Record<string, any>, string, string>': href, first_publication_date, last_publication_date, slugs, and 2 more.
  1. And lastly, even when accessing the data object which is supposed to contain my selected fields: const { image, title, excerpt, categories, authors } = data; I get this error:
Property 'image' does not exist on type 'PickContentRelationshipFieldData<{ id: "article"; fields: ["title", "image", "excerpt", { id: "categories"; fields: [{ id: "category"; customtypes: [{ id: "category"; fields: ["name", "color"]; }]; fields: [{ id: "category"; fields: [...]; }]; }]; }, { ...; }]; }, Simplify<...>, string> | undefined'.

To silence these, I am currently casting the field to a custom intersection type, but it feels hacky and I have to manually maintain the Pick list to match what I have selected in Slice Machine:

type FetchedArticle = ContentRelationshipField<"article"> &
  PrismicDocument<
    Pick<
      ArticleDocument["data"],
      "title" | "image" | "excerpt" | "categories" | "authors"
    >
  >;


const article = primary.article as FetchedArticle;

Am I approaching this the wrong way? How should I be handling these "Picked" relationship types so that they are recognized as valid Prismic documents and include the standard metadata fields like first_publication_date?

Thank you!

Hi there,

This is expected TypeScript behavior with Prismic content relationships. By default, TypeScript only knows that a content relationship is a link field, it does not automatically know which linked fields were fetched via fetchLinks or graphQuery. (Prismic People)

The recommended approach is to use a type predicate/helper function to narrow the type before accessing .data. This is especially useful for Slice fields and nested relationships. (Prismic People)

For example:

import * as prismicH from "@prismicio/helpers";
import * as prismicT from "@prismicio/types";
import { Content } from "@prismicio/client";

const hasParentData = <
  TContentRelationshipField extends prismicT.ContentRelationshipField
>(
  field: TContentRelationshipField
): field is TContentRelationshipField & {
  data: {
    parent: Pick<Content.PageDocument["data"], "title">;
  };
} => {
  return (
    prismicH.isFilled.contentRelationship(field) &&
    typeof field.data === "object" &&
    field.data !== null &&
    "parent" in field.data
  );
};

Then:

if (hasParentData(slice.primary.link)) {
  slice.primary.link.data.parent.title;
}

A few important notes:

  • isFilled.contentRelationship() only checks whether the relationship itself exists.

  • It does not tell TypeScript which linked fields were fetched.

  • The linked fields must also be included in your query via fetchLinks or graphQuery. (Prismic People)

We have a few community threads covering similar cases here:

Hope that helps clarify things a bit :slightly_smiling_face: