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.

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

Fragment spread on interface not typed properly in Typescript #4645

Open
alex-statsig opened this issue Mar 11, 2024 · 2 comments
Open

Fragment spread on interface not typed properly in Typescript #4645

alex-statsig opened this issue Mar 11, 2024 · 2 comments

Comments

@alex-statsig
Copy link
Contributor

Ran into a weird issue with interface types + fragments today. It seems like the TypeScript types allow you to pass a fragment that may not match (due to the object being a different type implementing an interface) but will silently break at runtime with nulls that shouldn't be possible. It doesn't even throw an error (which I did see while trying to fix this, when moving SomeFragment_blah inside ... on ConcreteA { ...SomeFragment_blah }).

schema:

type ConcreteA implements BaseType {
  name: String!
}
type ConcreteB implements BaseType {
  name: String!
}
type BaseType {
  name: String!
}

type Query {
  base_type(id: ID!): BaseType!
}

query:

query TestQuery {
  base_type(id: "test") {
    ...SomeFragment_blah
  }
}
fragment SomeFragment_blah on ConcreteA {
  name
}

usage:

...
const data = useLazyLoadQuery(query, {});
return <SomeFragment blah={data.base_type} />

This was problematic for me because I was refactoring some fragments to use a separate query for a dialog, and the behavior in this case changed (originally TestQuery was just a fragment on BaseType which could be used in either a query for ConcreteA or ConcreteB so I think it was deterministic per query which type it was, but now its ambiguous due to the base_type field).

I would expect data.base_type to be conditionally applicable as ConcreteA, perhaps requiring an alias or typename discriminator to practically do this. I was surprised it just silently failed in this case, leading to weird downstream issues for missing fields.

I can followup with a more solid repro / confirming this is true on latest versions, but just wanted to get the issue filed first.

@sairion
Copy link
Contributor

sairion commented May 8, 2024

experiencing the same thing.
For example, I wanted to add spread for common error types, which implements common Error interface.
In your example, I guess type BaseType -> interface BaseType?

I looked into relay-typgen's test case and could not find this case covered

@XiNiHa
Copy link

XiNiHa commented May 23, 2024

A Compiler Explorer reproduction that also includes some tricky cases: link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants