Generate undefined instead of null in typescript

[amol-c]

• feature

I think there has been an intense argument going around with null vs undefined in the JS community. But, in the typescript world, pretty much microsoft has recommended to avoid null and use undefined.

Can we have an option argument to generate undefined instead of null in typescript? Coming from swift world, it will be pretty useful to just deal with undefined than adding null to the mix.

Any thoughts?

[danilobuerger]

GraphQL uses null and undefined, so the typings would be wrong by not including null. Also see graphql/graphql-js#1298 (comment)

[irace]

I’m a strong +1 on this request.

While I do understand that the generated typings would be “wrong” in a sense, I don’t think that would actually be of any practical concern to a client-side developer dealing with generated TypeScript models.

From the comment linked to above:

null means that the field requested is not available (either due to being non-existent or from an error) while undefined (or absent from response) means that the field was not requested.

This is true, but since we’re generating our TypeScript models’ interfaces from our actual queries, the interfaces would never include a field that was not requested. As such, the distinction between “non-existent” and “not-requested” is not valuable.

[danilobuerger]

Following your logic

This is true, but since we’re generating our TypeScript models’ interfaces from our actual queries, the interfaces would never include a field that was not requested.

The typings should then include null and not undefined, not the other way around.

[danilobuerger]

Whats the usecase for wanting to use undefined instead of null? What problem does it solve?

[irace]

The distinction between undefined and null – while valuable in JavaScript – does not have the same value in TypeScript. As such, the TypeScript community has largely made a standard practice of just using undefined instead of null (here are Microsoft’s coding guidelines, which @amol-c linked to above).

[irace]

As such, it’s frustrating to try to interoperate generated models with nullable types into a codebase that uses undefined everywhere. Imagine a simple React component whose props look as follows:

interface P {
  name?: string;
}

I would not be able to pass apolloGeneratedModel.name into this component without first converting null to undefined – an unnecessary step in a codebase that has already decided that the distinction between null and undefined is not adding value, and that undefined is to be used in all cases as such.

[danilobuerger]

As such, the TypeScript community has largely made a standard practice of just using undefined instead of null

Source? Just because the TypeScript team doesn't use null doesn't mean its standard practice.

Lets assume we change it to undefined:

// graphql schema
type SomeType {
  bar: String
}
type Query {
  foo: SomeType
}

// graphql query
query someQuery {
  foo {
    bar
  }
}

// typescript bindings
interface someQuery_foo {
  __typename: "SomeType";
  bar?: string;
}
interface someQuery {
  foo?: someQuery_foo;
}

// return from server
{
  "data": {
    "foo": null
  }
}

// code
if (data.foo !== undefined) {
  // TypeScript now assumes this is of type someQuery_foo
  data.foo.bar
  // Uncaught TypeError: Cannot read property 'bar' of null
}

Nice! Now we have what we don't want. People shooting themselves in the foot because the typings are wrong.

[irace]

Right, I should have been more clear.

Simply changing the code generation would not be sufficient – the Apollo client would also need to be configured in such a way that it actually does the null → undefined conversion as well.

[amol-c]

As a temporary fix for our typescript codebase, we are using tpt-optchain (its a fork from rimeto/ts-optchain. Looks like the original library may have added the support) which pretty much treats null and undefined as the same.

This also makes optional unwrapping a bit easier.

[danilobuerger]

@irace How would you then handle partial results (which are not implemented yet in apollo-client but described here: https://github.com/apollographql/apollo-client/blob/master/packages/apollo-client/designs/errors.md)? If there is no more null you can't differentiate between a nullable type being present but null and it not being present because of an error therefor undefined?

[irace]

@danilobuerger Good question – I admittedly have not read this proposal, let me read it and get back to you.

Thanks for hearing me out.

[kevinthecity]

If there is no more null you can't differentiate between a nullable type being present but null and it not being present because of an error therefor undefined?

@danilobuerger It seems like if that proposal were implemented, that logic could / would be abstracted away from the consumer of the API inside of the Apollo client - as consumers we just want optional models, we don't really care about how the underlying implementation delivers it to us.

Similar to how a java / kotlin / swift client with generated models wouldn't be able to distinguish between null / undefined since it's not a feature of the language, ideally typescript shouldn't either.

[irace]

Yeah, I think the Swift point is a good one. Swift does not have separate notions of null vs. undefined, yet Apollo still supports generating Swift models.

If you’re building a TypeScript application and have decided to use undefined everywhere and null nowhere, then perhaps it’s more useful to think of that codebase as more analogous to a Swift codebase than to JavaScript one.