v10 typing includes EntryFieldTypes, but mismatches actual API response

[christianjung87]

Hi,
we would love to type our application with generated types from our contentful space.

When generating the types via CLI (with v10 flag activated), we get the following as a result

import type { ChainModifiers, Entry, EntryFieldTypes, EntrySkeletonType, LocaleCode } from 'contentful';
export interface TypeCeTextBlockFields {
  headline: EntryFieldTypes.Symbol;
  copy: EntryFieldTypes.Text;
  buttonText?: EntryFieldTypes.Symbol;
  buttonUrl?: EntryFieldTypes.Symbol;
}

export type TypeCeTextBlockSkeleton = EntrySkeletonType<TypeCeTextBlockFields, 'ceTextBlock'>;
export type TypeCeTextBlock<Modifiers extends ChainModifiers, Locales extends LocaleCode> = Entry<
  TypeCeTextBlockSkeleton,
  Modifiers,
  Locales
>;

But the actual API response (for the fields) looks somewhat like this:

{
 "headline": "test headline",
 "copy": "lorem ipsum dolor"
}

As far as I understand EntryFieldTypes is an extended Type which is an object with type and values, but the API returns the strings for example directly - so they mismatch.

Eventually I got a general misconception of how the type generation should work or do I need to adopt the API query? When Manually changing the Type from EntryFieldTypes.Symbol to EntryFields.Symbol I get the expected behavior, but of course that is not a proper solution for this use case.

[veu]

TypeCeTextBlockSkeleton is an abstract description of how the entry looks like using the EntryFieldTypes. It can be used in two ways:

• Pass it to the CDA methods to get the correct return type which matches your fetched entry data.
• Pass it to the Entry type together with the client configuration you’re using if you want to use the types in other parts of your code. The resulting type again matches your entry data. The generator creates the TypeCeTextBlock to make this a bit more convenient.

[jacksonopp]

I'm running up against a similar issue when it comes to resolved links within embedded entries inside rich text fields. Not sure if this is an issue with this library or with the ngx-contentful-rich-text library I'm using.

In this example, I'm creating a hero component based off of a hero content type.

The data that I have access to inside the component I'm rendering for the embedded asset matches the TypeHeroFields. I access this by essentially casting that data into the TypeHeroFields type. One of the fields in TypeHeroFields is a image content type, which is a wrapper content type around an asset (we're just adding some SEO fields to an asset basically). Since we're resolving that data in the CDA method, the type mismatches, since it's no longer a link, but the actual data.

I'm able to work around this by doing data.heroImage as unknown as Entry<TypeImageSkeleton>, but this doesn't seem to be the right pattern.

Sorry if this description is a little confusing. I can elaborate if you need me to.

[veu]

@jacksonopp You’re right. Resolved inks in rich text fields are currently not covered by the types in contentful.js. Feel free to file a feature request in contentful.js itself.

[veu]

Closing this issue in favor of contentful/contentful.js#1921