null vs undefined in TypeScript

[seancolsen]

I started working on enabling typescript strictNullChecks. As expected, I'm running into TS errors like this:

Type 'null' is not assignable to type 'string | undefined'

This error makes me wonder what sort of patterns we want to establish for using null values and types vs undefined values and types.

Personally, I've struggled with null vs undefined throughout my time with JavaScript. The fact that we have two separate values to represent such a similar concept is terrible language design in my opinion.

For example:

[0].find(i => i > 1) // undefined
"foo".match(/[A-Z]/) // null

I'm aware of various analogies that attempt to make sense of null vs undefined, but the concepts I'm usually trying to represent in code don't lend themselves well to a mental model that includes two distinct "empty" types. I've developed the opion that if a piece of code is relying on the distinction between null and undefined to convey meaning, then it's not designed with readability in-mind. So I usually gravitate towards a establishing a pattern of writing types primarily with null or with undefined -- but not with both -- on a per-codebase basis.

For example:

• With a preference for undefined:

  function firstNumberGreaterThanTen(numbers: number[]): number | undefined {
    return numbers.find(i => i > 10);
  }
  
  function firstCapitalLetter(s: string): string | undefined {
    return s.match(/[A-Z]/)?.[0] ?? undefined
  }

• With a preference for null:

  function firstNumberGreaterThanTen(numbers: number[]): number | null {
    return numbers.find(i => i > 10) ?? null;
  }
  
  function firstCapitalLetter(s: string): string | null {
    return s.match(/[A-Z]/)?.[0] ?? null
  }

I tend to prefer using undefined over null, but it's definitely not perfect. For example, you can't serialize an object with undefined values to JSON and preserve the keys.

As we work to make our types more strict, I'm wondering how we want to approach this problem of null vs undefined.

I'm hoping to avoid code with null and undefined mixed into the same type because it just gets messy.

function yuck(): string | null | undefined {
  //...
}

@pavish I'd love to hear your thoughts.

[dmos62]

I like that you're bringing this up and I think that enabling strictNullChecks will be a significant improvement. In my opinion, nulls should always be avoided. It doesn't have a use case not covered by undefined, and using both explodes the number of edge-cases. By the way, Tony Hoare, "father" of the null reference, calls it the billion dollar mistake [0], haha! Good luck with the refactors!

[0] https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/

[pavish]

@seancolsen @dmos62

I think we should go with undefined. I agree on the complexity it'll bring if we use both null and undefined. undefined is the most common return value for a number of inbuilt functions and I think it's more convenient to use it.

We would mostly only want to worry about serialization for handling requests and responses, where null would be essential, but I do not see any other case where we might require null.

In short, for type definitions and return types of functions, we would prefer undefined.
null will only be used where it is strictly necessary such as in requests and responses.

[dmos62]

Could you briefly expand on the use case for null when handling requests and responses?

[seancolsen]

Serializing and unserializing an object to JSON behaves differently. Here's an example:

JSON.parse(JSON.stringify({ a: 1, b: undefined }))   // { a: 1 }
JSON.parse(JSON.stringify({ a: 1, b: null }))        // { a: 1, b: null }

With undefined you lose that entry in the object. Depending on the situation it might not matter. I've run into this with VueJS because Vue's reactivity system relies on object schema being fixed at runtime. Vue has more magic than Svelte, which is one reason I prefer Svelte.

Even with Svelte, we'll need to be aware that if we pass an object like { a: 1, b: undefined} to the API, the server will see { a: 1 }. In most cases that's probably fine. Backend code probably should not behave any differently if it receives { "a": 1 } or { "a": 1, "b": None } from an API request. If we want to build an API that does respond differently to those requests, then we'll need to pass a null value so that they entry makes it to the server, but that probably wouldn't be the best API design anyway.

I wouldn't be surprised if there are other situations where null does things that undefined can't. This is just one situation that I've encountered.

[pavish]

Backend code probably should not behave any differently if it receives { "a": 1 } or { "a": 1, "b": null } from an API request

It does. Patch requests are usually partial objects that only update the values that are passed, in which case undefined can never be used. For example, { "a" : 1 } will only update a in the backend. If we want to update a to null in the db, we will have to pass { "a": null } as the request.

[seancolsen]

Great example

[dmos62]

Wasn't aware that JSON doesn't support undefined values. Cool! Look at this: JSON.stringify([undefined, undefined]) == "[null,null]".