Ability to specify resolved relations in generated types

[fvarano]

It would be useful to have the ability to specify which of the relation fields is expected to be resolved for a given Blok.
For example:

const justOneResolved: StoryWithRelations<'relation'> = {
	relation: [], // This is a ISbStoryData<RelatedStory>[]
	otherRelation: [], // This is a string[]
	_uid: '123',
	component: 'storyWithRelations'
};

const bothResolved: StoryWithRelations<'relation' | 'otherRelation'> = {
	relation: [], // This is a ISbStoryData<RelatedStory>[]
	otherRelation: [], // This is a ISbStoryData<RelatedStory>[]
	_uid: '123',
	component: 'storyWithRelations'
};

To achieve this, I experimented a bit with generics and some TS trickery, and something like this does the job:

// These are utility types
type Relation<
	Related,
	Field extends string,
	Resolved extends string | null | undefined = undefined
> = undefined extends Resolved
	? Related | string
	: null extends Resolved
		? string
		: Field extends Resolved
			? Related
			: string;

type RelationParameter<FieldName extends string> = FieldName | null | undefined;


// These would be the generated types for two content types
type RelatedStory = {
	anything: string;
	component: 'relatedStory';
	_uid: string;
	[k: string]: unknown;
};

interface StoryWithRelations<
	R extends RelationParameter<'relation' | 'otherRelation'> = undefined
> {
	relation?: Relation<ISbStoryData<RelatedStory>, 'relation', R>[];
	otherRelation?: Relation<ISbStoryData<RelatedStory>, 'otherRelation', R>[];
	component: 'storyWithRelations';
	_uid: string;
	[k: string]: unknown;
}

given this setup, a user would be able to specify which relations are expected to be resolved, or specify that none should be, like this.

// Default behavior, which makes these backwards compatible with types generated by the CLI today
const byDefault: StoryWithRelations = {
	relation: [], // This is a (ISbStoryData<RelatedStory> | string)[]
	otherRelation: [], // This is a (ISbStoryData<RelatedStory> | string)[]
	_uid: '123',
	component: 'storyWithRelations'
};

// Specify that NO relations are resolved
const noResolvedRelations: StoryWithRelations<null> = {
	relation: [], // This is a string[]
	otherRelation: [], // This is a string[]
	_uid: '123',
	component: 'storyWithRelations'
};

// When a string argument is passed, only the specified fields are resolved relations.
// This also provides autocompletion, since all relation fields are specified in the R type parameter for this content type.
const justOneResolved: StoryWithRelations<'relation'> = {
	relation: [], // This is a ISbStoryData<RelatedStory>[]
	otherRelation: [], // This is a string[]
	_uid: '123',
	component: 'storyWithRelations'
};

const bothResolved: StoryWithRelations<'relation' | 'otherRelation'> = {
	relation: [], // This is a ISbStoryData<RelatedStory>[]
	otherRelation: [], // This is a ISbStoryData<RelatedStory>[]
	_uid: '123',
	component: 'storyWithRelations'
};

I understand that adding type parameters to these kind of interfaces might be a risk for future changes, since TypeScript has no way of specifying Type< _ , "this" > without also specifying the first type parameter, but I thought this might be worth a discussion.

Ideally, UI components associated to a blok should cover any case for all relations to be either resolved or not, but in reality, since the code that decides whether to resolve those relations is in the same codebase, it often leads to many as string[] or as ISbStoryData<RelatedStory>[], which distributes the assumption.
With this capability, users could specify ideas like "this component expects these relations to be resolved", which is the full assumption, then the type system takes care of the rest.

What do you think?