feat: give includes basic entry and asset types instead of any #2363
Conversation
| @@ -339,7 +339,7 @@ export type EntryCollection< | |||
| > = ContentfulCollection<Entry<EntrySkeleton, Modifiers, Locales>> & { | |||
| errors?: Array<any> | |||
| includes?: { | |||
| Entry?: any[] | |||
| Asset?: any[] | |||
| Entry?: Entry<EntrySkeletonType, Modifiers, Locales>[] | |||
There was a problem hiding this comment.
I think we should not pass down the Locales variable here and use LocaleCode instead because linked entries might come from other spaces which can have different locales.
There was a problem hiding this comment.
So when we make cross-space requests we basically don't know anymore what locales we're dealing with?
That makes sense, but won't that then also already be broken in the more common case of actually using the link resolution, since there we cannot distinguish?
I'm a bit split between making it easy for the most common use case of not having cross space links, but a set of explicit locales, and ensuring that the types aren't misleading in the case where you use cross space links to spaces with a different set of locales.
I guess since the includes are also not returned in a structure where customers could provide something like a space / locale mapping that means we basically have no way to ever really have locale types that are anything other than string.
So I'm wondering, maybe it's better to keep using Locales which will probably in much more than 90% of cases be the expected behavior, and which you can at least put all the locales between the different spaces in as a workaround, instead of forcing includes to always have untyped locales.
There was a problem hiding this comment.
Yeah, you’re right. Even in most cross space cases the locales should be created to match and in cases that are more complicated the locale types probably won’t help much and have to be checked at runtime anyway in which case you would just use string and be correct.
|
🎉 This PR is included in version 11.2.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Summary
Gives includes Entry and Asset arrays at least basic skeleton types.
From there they can then conveniently be narrowed down to the desired types.
Description
Currently the types are
any, which is difficult to work with.Casting from the outside is awkward too especially since we have the modifiers that should propagate.
So we should just set the correct types from the start.
Motivation and Context
I need to do some processing on the includes and don't want to cast them all the time.