Union's resolveType doesn't know about __typename

[ThisIsMissEm]

I'm currently trying to build a graphql server that uses the Result Union's pattern described by @sachee, whereby fields that may error in normal operation when resolving them return Union type of something like union PostResult = NotFound | Post

There's a video describing this pattern here: https://www.youtube.com/watch?v=GYBhHUGR1ZY

However, if you have:

export const PostResult = unionType({
  name: 'PostResult',
  description:
    'A Post, or NotFound if the post was not found',
  definition(t) {
    t.members('Post', 'NotFound');
    t.resolveType(item => item.__typename);
  }
});

Then you get an error telling you that __typename isn't a property of item, even though your resolver for the field that uses this PostResult union can definitely return the __typename field.

export const Query = objectType({
  name: 'Query',
  definition(t) {
    t.field('post', {
      type: PostResult,
      args: {
        id: idArg({ required: true })
      },
      resolve(root, { id }) {
        try {
          const post = await Posts.findById(id)
          return { __typename: "Post", ...post }
        } catch(err) {
          return { __typename: "NotFound", message: `Could not find post with ID: ${id}` }
        }
    });
  }
});

I think the type assigned to the callback argument in t.resolveType should have the __typename property available.

For now, I'm able to work-around this by using item['__typename'] but that's a pretty ugly hack.

[ThisIsMissEm]

Looks like it's possible to get this working by modifying typegenHelpers.d.ts to have:

export declare type ResultValue<
  TypeName extends string,
  FieldName extends string
> = GetGen3<'fieldTypes', TypeName, FieldName> & { __typename: string };

I've no idea how to actually get this as a proper fix though. Well, that was just part of it, to be able to correctly return __typename from a resolver for a union.

[tgriesser]

This is indeed an oversight and something I recently also realized/encountered as well when trying to build some union types using the same pattern from that talk.

Will look to get a fix in for this soon!

[jasonkuhrt]

I think the type assigned to the callback argument in t.resolveType should have the __typename property available.

Agree. We will need to make this invariant safe though. For example, making the resolver for a union-typed field be forced to include __typeName in the returned data. I expect more details to sort out than this.

[jasonkuhrt]

This feels like a bug to me, more than a feature.

[ThisIsMissEm]

For example, making the resolver for a union-typed field be forced to include __typeName in the returned data

This makes sense to me.

[tgriesser]

Started thinking more about this, and there's a few things to address here.

First, I believe the messaging / behavior of the current warning message is incorrect:

... or t.resolveType(() => null) if you don't want or need to implement.

You should always implement this somehow, () => null is useless for union types.

The question is really whether you want a custom resolve or whether you just want the default behavior, as @ThisIsMissEm is re-implementing by hand with the item => item.__typename.

If you are in-fact providing the __typename, then you can use the default one. As such, I was planning on changing the messaging/behavior to:

... or t.resolveType() if you want to use GraphQL's defaultTypeResolver and hide this warning.

So essentially if you call t.resolveType() with no arguments, it'll use defaultTypeResolver with behavior detailed here.

The tricky thing with typings here is that if you are using the default execution algorithm, __typename should be required for member types, but if you have a custom one then we shouldn't necessarily require __typename be specified, since that's the point of defining the custom resolveType.

@ThisIsMissEm does this sound like a reasonable approach/change to the issue you describe?

I was thinking of adding the change in the messaging / ability to call t.resolveType() for the soon to be released 0.12.0 and then address the __typename as part of the refactor of type generation in the next release.

[ThisIsMissEm]

So all unions will have to be written as:

export const PostResult = unionType({
  name: 'PostResult',
  description: 'A Post, or NotFound if the post was not found',
  definition(t) {
    t.members('Post', 'NotFound');
    t.resolveType();
  }
});

Wouldn't it be better to do:

export const PostResult = unionType({
  name: 'PostResult',
  description: 'A Post, or NotFound if the post was not found',
  definition(t) {
    t.members('Post', 'NotFound');
  }
});

Or even:

export const PostResult = unionType({
  name: 'PostResult',
  description:
    'A Post, or NotFound if the post was not found',
  members: ['Post', 'NotFound']
});

[tgriesser]

As I suggested, yes, though I suppose I was only looking at it as an improvement on the current alternative - rather than revisiting why it is how it is...

export const PostResult = unionType({
  name: 'PostResult',
  description:
    'A Post, or NotFound if the post was not found',
  members: ['Post', 'NotFound']
});

IIRC this API wasn't originally possible it was due to some issues w/ type completion/safety on object members not being correct, I think I left a comment about this as a reminder for a similar issue on interfaces, need to revisit if anything has changed here:

https://github.com/prisma-labs/nexus/blob/38fe229a1971f975f6ce60c8c3a6208856d72938/src/definitions/interfaceType.ts#L17-L22

It looks like the PR referenced there got merged, so maybe it is supported now? Will give it a shot and see if we can adjust/simplify the API here.

I guess we could also make the assumption that if resolveType isn't defined, __typename would be required on any possible union members?