Ability to customize the "null type"

[kasper573]

Other codegen based typescript graphql clients have support for customizing the generated Maybe type (See typescript-operations).

I think it makes sense to support something similar in gql.tada.

I personally avoid null like the plague and prefer to use undefined as my optional state. None of my UI code uses null, which makes integrating with a gql.tada client really awkward since I have to constantly transform nulls to undefined manually.

[kitten]

This is actually a big weakness in GCG: Correctness by default and the vast amount of configurability that is either needed to be more correct on type outputs, or the configuration that only makes types less correct.

This is one such case.

We make sure that all generated types follow a high level of correctness to the GraphQL spec's generated output and there's little wiggle room in that spec for a reason. To put it short, semantically having both null and undefined is an important distinction and in fact useful in GraphQL.

In a GraphQL API's resolvers for instance, it doesn't matter much.
However when it comes to JSON serialisation in general, it's important to adhere to what the API actually returns.

Nullable fields are selected fields in the GraphQL API and must return either a value or null since that's a set JSON value.
However, undefined, which isn't explicitly used in the output signifies that a value is absent.
In GraphQL that can only happen when the value is skipped, for example, when @skip or @include are conditional.

There are some cases where GCG actually defaults to less correct type outputs and this can easily lead to mistakes, since the types don't convey the actual JSON type you'll get and don't convey the semantic difference in JS and GraphQL that you get.

Once you enter presentational components that don't specify any colocated fragments you're of course free to convert and map to anything.
But if you receive data from your GraphQL clients the difference between a value being nullable and not present is in fact important

[kasper573]

I do like the correctness by default principle. Generally i also believe it’s healthy to lead users away from harmful (but convenient) practices, and configuration options can definitely be just that.

But that doesn’t mean that all options inherently are bad practice. I guess it’s a judgement call on where one draws the line: Is it more harmful than helpful to introduce an option like this?

in my case I acknowledge the semantic difference between null and undefined in the graphql spec, but I willingly disregard the nuance it yields in favor of type compatibility out of the box. My company has so many foreign UI components without null support that we cannot alter (and should not alter, since they are general components that have no notion about graphql). For us the tradeoff is definitely worth it.

[kitten]

If you're following fragment co-location, it shouldn't really matter though: https://gql-tada.0no.co/guides/fragment-colocation
As I meant with that, if you have many presentational components, and you happen to assume that every type annotated as | null or | undefined there can be either, then that's something that'd have to be mapped over when going from a structural GraphQL component with a colocated fragment to a presentational component.

Our explicit goal isn't to be compatible with all possible GraphQL Code Generator and GraphQL setups, as that's unfortunately not possible.

And additionally, we found that no extra configuration apart from the ones we now have is likely needed, assuming we simply infer and generate only correct types, and ignore options from GCG's various presets that diverge from that approach.

Again, I appreciate that that limits you in your specific case, but say, we switch a GraphQL result over to | undefined — that doesn't guarantee anything for the GraphQL client. If your transport happens to normalises data in any way (correct or not), you're likely more well served with it also remapping types with a conditional type,
so I'd suggest to maybe look into that.

But a careful warning that optional unions and | undefined has a special place in the generated types, that are very tied to correctness, and that if you map every result type to | undefined (on types and the transport) that you then may run into trouble in the future with @defer, and currently, with @skip and @include, for example ✌️

[kitten]

Just to follow up on this too, sorry ❤️

But I’m not sure if that applies here. I guess it’s a judgement call on where one draws the line: Is it more harmful than helpful to introduce an option like this?

That's not our design goal. It's neither:

• parity with GCG's default options (which make some controversial choices)
• parity with options, except for ones that obviously lead to the exact/correct output we strive for
• options in general (if everything's configurable, nothing is configured, and it becomes overwhelming — we can't cater for all)

In general, from a DX perspective, my take is that the line isn't at all at harmful v helpful. Everything's helpful to someone, and every API/design decision will be used and abused by someone in some way, and on top of that every configuration option and additional usage path adds complexity. So, while that's not what you wanted to hear, and I'm sorry about that, less is more here imho

[kasper573]

Yeah, that’s what I was suspecting. It is a fair philosophy, very strict and stable architectural bounds. I respect that. Thanks for explaining so thoroughly!