null instead of undefined

[imbroyury]

Hello @aexol, thanks for your amazing library.

The generated type for nullable fields in v4.0.4 is ... | undefined while in reality the runtime type is ... | null.

The issue was originally reported in https://github.com/graphql-editor/graphql-zeus/issues/171 and https://github.com/graphql-editor/graphql-zeus/issues/184 for v3, it came back and is reproduced in v4.0.4 https://github.com/graphql-editor/graphql-zeus/issues/171#issuecomment-1059293427, likely because of commit https://github.com/graphql-editor/graphql-zeus/commit/a338a8dd14344c0d39deaba67cf17514231347ad.

Can you give an update on this? Do you plan to replace undefined with null? Perhaps, in v5? If no, why?

[aexol]

Maybe some day with a flag later. Using nulls make using Zeus extremely painful

[imbroyury]

Thanks for your prompt reply 🙌

But isn't it ultimately a caveat of using a GraphQL API? If a server is sending over null for a nullable field as an indication of no value, a developer shouldn't lie to him/herself for convenience.

[aexol]

They should. It is much easier to manage those objects without nulls. However we can make a config file for zeus to maintain all those flags like nulls vs undefined

[ValentinH]

We are using Zeus heavily on our codebase with a patch to use null for nullable values. I don't understand what do you mean by "much easier"?

[imbroyury]

@aexol it seems like it's not just me, so can you please elaborate on the "much easier" part of null vs undefined for other users of the library? 🙂 very interested in your point of view on the problem

[aexol]

ok, if you have an object stored and you want to provide values from the frontend side, then every optional field if the type is inferred by Zeus has to be manually typed as null and that doesn't make sense at all. You could have just written types by hand.

https://zeus.graphqleditor.com/page/selector.html

[imbroyury]

@aexol sorry, I don't think I understand why "every optional field if the type is inferred by Zeus has to be manually typed as null"? can't Zeus infer types as | null?

[ValentinH]

@aexol for your example, if I need to insert something from the frontend, let's say a user, each field will be optional because ValueTypes is used:

Data returned by the API is typed by the GraphQLTypes where the non-required field are typed as null (non-optional):

[aexol]

I will provide an example when I will have time for that

[FilipChalupa]

@aexol do you have any updates please?

[GauBen]

I just ran into an issue because of this. null and undefined do not behave exactly the same:

const {x = 1, y = 2} = {x: undefined, y: null};
console.log(x, y); // 1, null

– A developer shouldn't lie to theirself for convenience. – They should.

Absolutely not, this feature is breaking type safety.

[ValentinH]

@aexol would you accept a PR where we enable this to be configured via a flag?

I've been maintaining a fork of v4 for a few months and most changes are now useless thanks to the nice changes of v5. I've only this case + another (I'll create a dedicated issue) that avoids us to use the official version 😅

If this can be useful to someone else, here's the commit on our fork to use null instead of undefined for the returned data ModelTypes/GraphQLTypes: elba-security/graphql-zeus@f298564 (#6)

[imbroyury]

@aexol any updates on this?

[GauBen]

@ValentinH Here is a small update to your diff: you need to update MapType to the following

export type MapType<SRC, DST, SCLR extends ScalarDefinition> = SRC extends null
  ? null
  : SRC extends DeepAnify<DST>
    ? IsInterfaced<SRC, DST, SCLR>
    : never;

Otherwise, the Type | null union gets its null smashed by SRC extends DeepAnify<DST>

TypeScript playground

It would be nice to have this fixed directly in Zeus :)

[ValentinH]

Thanks for sharing this.

FWIW we have decided to migrate to https://the-guild.dev/graphql/codegen as the Zeus codegen size (more than 200k LOC as of today) was getting way too big for us (and for Next.js, tsc and VSCode 😅). Also being able to author real Graphql is in the end is win as we don't have to teach yet another tech to the team and we can benefit from more tooling.

[GauBen]

I was thinking of making the same move for a while now, but with Houdini taking care of the plumbing. Thanks for your tip!

[ValentinH]

Interesting approach!