Open imbroyury opened 2 years ago
Maybe some day with a flag later. Using nulls make using Zeus extremely painful
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 null
able field as an indication of no value, a developer shouldn't lie to him/herself for convenience.
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
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"?
@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
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.
@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
?
@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):
I will provide an example when I will have time for that
@aexol do you have any updates please?
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.
@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)
@aexol any updates on this?
@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>
It would be nice to have this fixed directly in Zeus :)
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.
I was thinking of making the same move for a while now, but with Houdini taking care of the plumbing. Thanks for your tip!
Interesting approach!
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
withnull
? Perhaps, in v5? If no, why?