Better return types for `.__type__.name` and polymorphic queries if possible

[jaclarke]

Describe the proposed feature A clear and concise description of the syntax, what you want to happen, and why it's needed.

Part 1. __type__.name

Currently the return type of .__type__.name is just string. We know the name of the object type that's being selected, so it should be possible to infer this as the correct string literal (or union of string literals if it's a parent type).

Part 2. Polymorphic queries

Currently a query like this:

e.select(e.Content, () => ({
  title: true,
  ...e.is(e.Movie, { release_year: true }),
  ...e.is(e.TVShow, { num_seasons: true }),
}));

gets a return type like:

{
  title: string;
  release_year: number | null;
  num_seasons: number | null;
}[]

While this is technically correct, it would be more useful if we could return a discriminated union. I think it might be possible for the querybuilder to automatically insert the typename in the shape, and return a type like so:

({
  title: string;
} & ({
  __typename: 'default::Movie';
  release_year: number;
} | {
  __typename: 'default::Show';
  num_seasons: number;
}))[]

[TechSupportJosh]

This would be fantastic! Being able to return discriminated unions here would be very beneficial for applications using something like tRPC, which lets you then have discriminated unions on your frontend.

[datner]

Invaluable! Eliminates redundant checking just to satisfy the parser!

[pk-nb]

This would be incredibly useful! Right now the returned types for a polymorphic link are quite difficult to work with. Any chance this could get attention again?

[scotttrinh]

@pk-nb

No timeline on this yet, but it's on my radar to try to bring the linked PR current against master. There are some potential interactions between this and some other issues with polymorphic types that I'll want to be careful with, so it might be a bit more involved from a QA perspective.

[janwirth]

Ping