Validation: Assuming the Worst

Six chapters have pointed here, which is more than any other chapter in this book. Worth listing, because they’re all the same problem:

• Chapter 5: Number("banana") gives NaN, and it prints like an answer.
• Chapter 10: scores[10] is typed number and holds undefined.
• Chapter 14: .find() is honest about failing, indexing isn’t.
• Chapter 16: a bad value got clamped, and you were told that was a decision rather than the answer.
• Chapter 17: JSON.parse returns any, and annotating it is a promise nobody checked.
• Chapter 18: .get() might not find anything.

Every one is the same shape: something arrived from outside, and your types were a hopeful description of it.

any versus unknown

Chapter 3 met any, the opt-out. Here’s what it actually costs:

const a: any = "hello";

console.log(a.toUpperCase());
console.log(a.nonsense.at.all);

Both lines compile. The second one is obvious nonsense and TypeScript has switched off, so it says nothing. That’s any: not “I don’t know what this is”, but “stop checking”.

There’s a second type for the honest version:

const u: unknown = "hello";
console.log(u.toUpperCase());

error TS18046: 'u' is of type 'unknown'.

unknown also means “could be anything”, and it refuses to let you do anything at all with the value until you’ve established what it is.

That’s the difference, and it’s the whole chapter in two lines. any says trust me. unknown says prove it.

Narrowing

Proving what something is means asking. TypeScript watches the questions you ask and updates what it thinks you have:

function describe(u: unknown): string {
  if (typeof u === "string") return `string of length ${u.length}`;
  if (typeof u === "number") return `number ${u.toFixed(1)}`;
  if (Array.isArray(u)) return `array of ${u.length}`;
  if (u === null) return "null";
  return `something else: ${typeof u}`;
}

console.log(describe("hi"));
console.log(describe(3));
console.log(describe([1, 2]));
console.log(describe(null));
console.log(describe({ a: 1 }));

string of length 2
number 3.0
array of 2
null
something else: object

Look at u.length on the first line. That would be an error on an unknown, and inside the if it’s fine, because typeof u === "string" proved it. That’s narrowing: the type of u is different in different parts of the function, decided by what you’ve checked.

Array.isArray is the one to remember for arrays, because typeof [] is "object", which tells you almost nothing. And null needs its own check for the same reason: typeof null is also "object", a famous JavaScript wart that has been left alone for thirty years because fixing it would break the web.

When something might not be there

Chapter 12’s objects can have properties that are sometimes absent, marked with a ?:

type Book = { title: string; author?: { name: string } };

const a: Book = { title: "Dune" };
console.log(a.author.name);

error TS18048: 'a.author' is possibly 'undefined'.

TypeScript caught it. The fix could be an if, and for one property that’s fine, but chains get tedious fast. So there’s a shorter way:

console.log(a.author?.name);

undefined

?. is optional chaining: if the thing on the left is null or undefined, stop and give back undefined instead of reaching further. Otherwise carry on. It chains as far as you like, and any link failing ends the whole thing quietly.

Choosing a fallback

undefined is rarely what you want to print, so pair it with ??:

console.log(a.author?.name ?? "unknown");

unknown

?? is nullish coalescing: use the left side unless it’s null or undefined, in which case use the right.

You may have seen || used for the same job, and it is not the same job.

Checking a whole shape

Now chapter 17’s problem, properly. That chapter parsed a file, annotated it Task[], and the annotation was a claim nobody verified.

You can write the verification yourself:

type Task = { title: string; done: boolean };

function isTask(value: unknown): value is Task {
  if (typeof value !== "object" || value === null) return false;
  const c = value as Record<string, unknown>;
  return typeof c.title === "string" && typeof c.done === "boolean";
}

The return type is the new part. value is Task says: this function returns a boolean, and when it returns true, TypeScript should treat the argument as a Task from then on. That’s a type predicate, and it’s how you teach the compiler a check it couldn’t work out alone.

Inside, it’s ordinary code. Rule out non-objects and null, then look at each property with typeof.

Now the loader:

function loadTasks(text: string): Task[] {
  const parsed: unknown = JSON.parse(text);

  if (!Array.isArray(parsed)) {
    console.error("Not a list. Starting empty.");
    return [];
  }

  const good: Task[] = [];
  for (const item of parsed) {
    if (isTask(item)) {
      good.push(item);
    } else {
      console.error("Skipping a bad entry:", JSON.stringify(item));
    }
  }
  return good;
}

Skipping a bad entry: {"title":"Bad","done":"yes"}
Skipping a bad entry: {"nothing":1}
[ { title: 'Real', done: false } ]

Note const parsed: unknown. Chapter 17 wrote : Task[] there and got a lie. Writing unknown instead means TypeScript won’t let you touch it until you’ve checked, and by the time good is returned, its type is earned rather than asserted.

The complaints go to console.error, which chapter 11 introduced and chapter 17 showed you how to redirect. A program that skips bad data silently is worse than one that crashes.

Closing chapter 10’s hole

One thing left. Chapter 10 showed scores[10] typed number while holding undefined, and said it was the one place the type system simply lies.

There’s a switch for it:

npx tsc --noUncheckedIndexedAccess scores.ts

error TS2322: Type 'number | undefined' is not assignable to type 'number'.

With that flag on, every array index gives you T | undefined, and you have to check before using it. The lie is gone.

It’s off by default because turning it on in an existing codebase produces hundreds of errors, most of them on indexes that were genuinely fine. That’s a real cost, and it’s why it’s a choice rather than the rule.

function toCount(text: string): number | undefined

function isTask(value: unknown): value is Task