strictNullChecks

By default null and undefined are assignable to all types in TypeScript e.g.

  1. let foo: number = 123;
  2. foo = null; // Okay
  3. foo = undefined; // Okay

This is modelled after how a lot of people write JavaScript. However like all things, TypeScript allows you to be explicit about what can and cannot be assigned a null or undefined.

In strict null checking mode, null and undefined are different:

  1. let foo = undefined;
  2. foo = null; // NOT Okay

Let say we have a Member interface:

  1. interface Member {
  2. name: string,
  3. age?: number
  4. }

Not every Member will provide their age, so age is an optional property, meaning the value of age may or may not be undefined.

undefined is the root of all evil. It often leads to runtime errors. It is easy to write code that will throw Error at runtime:

  1. getMember()
  2. .then(member: Member => {
  3. const stringifyAge = member.age.toString() // Cannot read property 'toString' of undefined
  4. })

But in strict null checking mode, this error will be caught at compile time:

  1. getMember()
  2. .then(member: Member => {
  3. const stringifyAge = member.age.toString() // Object is possibly 'undefined'
  4. })

Non-Null Assertion Operator

A new ! post-fix expression operator may be used to assert that its operand is non-null and non-undefined in contexts where the type checker is unable to conclude that fact. For example:

  1. // Compiled with --strictNullChecks
  2. function validateEntity(e?: Entity) {
  3. // Throw exception if e is null or invalid entity
  4. }
  5. function processEntity(e?: Entity) {
  6. validateEntity(e);
  7. let a = e.name; // TS ERROR: e may be null.
  8. let b = e!.name; // OKAY. We are asserting that e is non-null.
  9. }

Note that it is just an assertion, and just like type assertions you are responsible for making sure the value is not null. A non-null assertion is essentially you telling the compiler “I know it’s not null so let me use it as though it’s not null”.

Definite Assignment Assertion Operator

TypeScript will also complain about properties in classes not being initialized e.g.:

  1. class C {
  2. foo: number; // OKAY as assigned in constrcutor
  3. bar: string = "hello"; // OKAY as has property initializer
  4. baz: boolean; // TS ERROR: Property 'baz' has no initializer and is not assigned directly in the constructor.
  5. constructor() {
  6. this.foo = 42;
  7. }
  8. }

You can use the definite assignment assertion postfixed to the property name to tell TypeScript that you are initlizing it somewhere other than the constructor e.g.

  1. class C {
  2. foo!: number;
  3. // ^
  4. // Notice this exclamation point!
  5. // This is the "definite assignment assertion" modifier.
  6. constructor() {
  7. this.initialize();
  8. }
  9. initialize() {
  10. this.foo = 0;
  11. }
  12. }

You can also use this assertion with simple variable declarations e.g.:

  1. let a: number[]; // No assertion
  2. let b!: number[]; // Assert
  3. initialize();
  4. a.push(4); // TS ERROR: variable used before assignment
  5. b.push(4); // OKAY: because of the assertion
  6. function initialize() {
  7. a = [0, 1, 2, 3];
  8. b = [0, 1, 2, 3];
  9. }

Like all assertions, you are telling the compiler to trust you. The compiler will not complain even if the code doesn’t actually always assign the property.