null, undefined and strictNullChecks

New words in this topic, in plain English. Come back here whenever one feels fuzzy.

undefined

The value of something never set: a missing property, an uninitialised variable, an out-of-range item.

null

A value placed on purpose to mean "nothing here".

strictNullChecks

A compiler flag (part of strict) that stops null and undefined from being allowed in every type.

Optional chaining ?.

Reads a property or calls a function only if the thing before it isn't null or undefined, else gives undefined.

Nullish coalescing ??

a ?? b gives a, unless a is null or undefined, then it gives b.

Falsy

Treated as false in an if: false, 0, "", null, undefined, NaN.

Non-null assertion !

A postfix ! that tells the checker a value is not null or undefined, with no proof.

Definite assignment

The rule that a variable must have a value before it is read. ! after the name says you'll handle it.

TypeError

The runtime error JavaScript throws, for example when you read a property of null.

1. 1

   Fix the crash with a check

   In the first example rewrite cityOf as if (user.address === null) return "unknown"; return user.address.city;. The error disappears: after the if, the checker knows address is not null.

2. 2

   Pick the right fallback

   Add console.log(withOr(0) === withNullish(0)); to the first example and predict the result before running. It prints false, because 10 is not 0.

3. 3

   Guard the element

   In the second example replace the last line with input?.focus();. Both the error and the crash are gone: if the element is missing, nothing happens. Then try if (input) { input.focus(); }.

Errors are the best teachers. Make each change, read the error, guess what went wrong, then reveal the answer.

1. 1

   The problem this solves: A value that is sometimes missing crashes the program the moment you use it, with the error "cannot read properties of undefined". Strict null checking makes you handle the missing case first. **undefined is the value JavaScript gives to anything that was never set: a variable with no value, a missing property, an item past the end of a list, a function that returns nothing. null** is a value *you* put somewhere on purpose to mean "there is nothing here". They are two different values with two different types, and the difference is mostly convention: undefined for "not set yet", null for "deliberately empty".

2. 2

   The trouble is what happens next. Reading a property of null or undefined (user.address.city when address is null) crashes with TypeError: Cannot read properties of null. This is the most common runtime error in JavaScript. Its inventor, Tony Hoare, who added the null reference to a language in 1965, later called it his billion-dollar mistake because of the bugs and crashes it caused across the industry.

3. 3

   TypeScript's answer is the flag **strictNullChecks** (part of strict, so on in new projects). With it off, null and undefined can be assigned to every type, and the checker is blind to the crash. With it on, they are separate types: string no longer means "a string or null". A value that really may be missing says so in its type with a union: **string | null or number | undefined**. Whenever you use such a value the checker asks you to rule out the missing case first.

4. 4

   Ruling it out takes one of four forms. A check: if (user.address !== null) { ... }. **Optional chaining ?.**: user.address?.city reads city only if address isn't null or undefined, and otherwise stops and gives undefined for the whole expression. **Nullish coalescing ??**: a ?? "unknown" gives a unless it is null or undefined, in which case it gives the fallback. And **!**, below. Optional chaining and ?? arrived in TypeScript 3.7 and are plain JavaScript today.

5. 5

   Use ??, not ||, for defaults. a || 10 replaces *every falsy value*: 0, "" and false too, so a quantity of 0 becomes 10. a ?? 10 replaces only null and undefined, so 0 stays 0 (the example below runs both). The same care applies to if (value) checks on numbers and strings: the number 0 is a perfectly good value but is falsy (Topic 4.3 digs into this).

6. 6

   The **non-null assertion !** (document.getElementById("app")!) tells the checker "I know this isn't null". It removes the error but not the risk: if you are wrong the program crashes at runtime, exactly like in plain JavaScript (see the last example). It is a promise you make without proof; prefer a real check or ?., and use ! only where the program's structure guarantees the value (Topic 5.6 covers assertions generally).

7. 7

   Related: definite assignment. Declare let total: number; with no value and read it before assigning, and the checker says TS2454: Variable 'total' is used before being assigned. If you know a value will be set in a way the checker can't see (a framework fills it in, an init() method), let ready!: number; or in a class name!: string silences it. As with !, the promise is yours to keep.

• ↔

  strictNullChecks adds handling code, but you write the check once and every caller after it is safe. The alternative is a TypeError in production.

• ↔

  Optional chaining can hide a real bug: a?.b?.c quietly gives undefined when you expected data. Use it where missing data is a normal state, and fail loudly (throw, or return an error value, Topic 13.5) where it is not.

• I can explain the billion-dollar mistake and how strictNullChecks addresses it.

• I can write T | null and handle it with an if, ?. and ??.

• I can explain why ?? is the right default operator and || is not.

• I can explain what ! and let x!: T promise, and what happens if they are wrong.

• I can read TS18047, TS18048 and TS2454 and fix them.