v10 typing includes EntryFieldTypes, but mismatches actual API response about cf-content-types-generator HOT 4 CLOSED

@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.

from cf-content-types-generator.

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

from cf-content-types-generator.

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.

from cf-content-types-generator.

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.

from cf-content-types-generator.