Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
jaclarke opened this issue Sep 28, 2022 · 4 comments · May be fixed by #508
Open

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

jaclarke opened this issue Sep 28, 2022 · 4 comments · May be fixed by #508
Assignees
@scotttrinh

Comments

@jaclarke
Copy link
Member

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;
}))[]
@jaclarke jaclarke self-assigned this Sep 28, 2022
@TechSupportJosh
Copy link

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
Copy link

datner commented Oct 3, 2022

Invaluable! Eliminates redundant checking just to satisfy the parser!

@jaclarke jaclarke linked a pull request Dec 12, 2022 that will close this issue
Draft
@pk-nb
Copy link

pk-nb commented Jun 4, 2023

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?

@raddevon raddevon assigned scotttrinh and unassigned jaclarke Jun 5, 2023
@scotttrinh
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@scotttrinh scotttrinh

Labels
None yet
Projects
None yet
Milestone
No milestone
5 participants
@scotttrinh @pk-nb @jaclarke @TechSupportJosh @datner