TypeScript Narrowing

This lesson is a TypeScript code lab for Overview. Start with a small executable case, then inspect the values, static contract, runtime boundary, and failure behavior before introducing framework code.

Every example has an observable result and a small change to make. That discipline turns syntax into an engineering habit that survives refactors and real input.

Five focused TypeScript programs that separate compile-time guarantees from runtime validation. Keep public boundaries narrow, test input changes deliberately, and return results a caller can use or verify.

This focused TypeScript Narrowing program demonstrates one rule. Run it, change one input, and explain why the type contract and the runtime result still agree.

TypeScript

function description(value: unknown): string {
  return typeof value === "string" ? value.trim() : "missing";
}

console.log(description(" Narrowing "));

Narrowing

Try next: change the nearest boundary or missing-value case and make the new behavior explicit rather than relying on a silent fallback.

This focused TypeScript Narrowing program demonstrates one rule. Run it, change one input, and explain why the type contract and the runtime result still agree.

TypeScript

type Result = { ok: true; value: number } | { ok: false; message: string };

function display(result: Result): string {
  return result.ok ? "value=" + result.value : "error=" + result.message;
}

console.log(display({ ok: false, message: "missing" }));

error=missing

Try next: change the nearest boundary or missing-value case and make the new behavior explicit rather than relying on a silent fallback.

This focused TypeScript Narrowing program demonstrates one rule. Run it, change one input, and explain why the type contract and the runtime result still agree.

TypeScript

type Topic = { title: string };

function hasTitle(value: unknown): value is Topic {
  return typeof value === "object" && value !== null && typeof (value as { title?: unknown }).title === "string";
}

const payload: unknown = { title: "Guards" };
console.log(hasTitle(payload) ? payload.title : "invalid");

Guards

Try next: change the nearest boundary or missing-value case and make the new behavior explicit rather than relying on a silent fallback.

This focused TypeScript Narrowing program demonstrates one rule. Run it, change one input, and explain why the type contract and the runtime result still agree.

TypeScript

function ownerName(owner: { name: string } | null): string {
  if (owner === null) return "unassigned";
  return owner.name;
}

console.log(ownerName(null));

unassigned

Try next: change the nearest boundary or missing-value case and make the new behavior explicit rather than relying on a silent fallback.

This focused TypeScript Narrowing program demonstrates one rule. Run it, change one input, and explain why the type contract and the runtime result still agree.

TypeScript

type State = "loading" | "ready";

function stateLabel(state: State): string {
  switch (state) {
    case "loading": return "Loading";
    case "ready": return "Ready";
  }
}

console.log(stateLabel("ready"));

Ready

Try next: change the nearest boundary or missing-value case and make the new behavior explicit rather than relying on a silent fallback.

Start by naming the value the next line depends on. This keeps the lesson input explicit before we apply a transformation or call an external boundary. We are applying that habit while revisiting TypeScript Narrowing.

Keep the example small enough to trace. First predict the normal result; then change one input and explain the boundary result in your own words.

TypeScript

const lesson: string = "TypeScript Narrowing";
console.log(lesson.toUpperCase());

TYPESCRIPT NARROWING

Try next: Replace the sample value with one from your own notes, predict the result, and then run it.

A small guard makes the allowed and rejected path visible. We want a caller to receive an intentional result instead of discovering an unexplained failure later. We are applying that habit while revisiting TypeScript Narrowing.

Keep the example small enough to trace. First predict the normal result; then change one input and explain the boundary result in your own words.

TypeScript

function accepted(value: string | undefined): boolean {
  return Boolean(value?.trim());
}

console.log(accepted("TypeScript Narrowing"));

true

Try next: Try an empty value as well as the normal value and describe why the two outcomes differ.

This step returns a value instead of mixing the rule with display or storage work. That separation gives us a small unit we can run, test, and reuse. We are applying that habit while revisiting TypeScript Narrowing.

Keep the example small enough to trace. First predict the normal result; then change one input and explain the boundary result in your own words.

TypeScript

const double = (value: number): number => value * 2;
console.log(double(6));

12

Try next: Call the same rule twice with different inputs and confirm that each result depends only on its input.

Use a named branch where the business rule changes. A future reader should be able to point at the condition and state the result for both sides. We are applying that habit while revisiting TypeScript Narrowing.

Keep the example small enough to trace. First predict the normal result; then change one input and explain the boundary result in your own words.

TypeScript

const score: number = 7;
const result: string = score >= 5 ? "ready" : "review";
console.log(result);

ready

Try next: Change the boundary value by one and explain exactly which branch becomes active.

Collections become safer when we can see which value is read, which value is derived, and whether the original collection remains owned by the caller. We are applying that habit while revisiting TypeScript Narrowing.

Keep the example small enough to trace. First predict the normal result; then change one input and explain the boundary result in your own words.

TypeScript

const lessons: readonly string[] = ["TypeScript Narrowing", "boundary"];
console.log(lessons.join(" | "));

TypeScript Narrowing | boundary

Try next: Add one more item and predict the derived result before executing the code.

A named outcome is easier to test than an implied side effect. We can now distinguish a successful path from a rejected path without guessing from console noise. We are applying that habit while revisiting TypeScript Narrowing.

Keep the example small enough to trace. First predict the normal result; then change one input and explain the boundary result in your own words.

TypeScript

type Outcome = { status: "ready"; lesson: string };
const outcome: Outcome = { status: "ready", lesson: "TypeScript Narrowing" };
console.log(outcome.status);

ready

Try next: Rename the outcome in your own words while preserving the same success and failure rule.

Work through one value at a time. The point is not to memorize syntax; it is to see how the accumulator or output changes after each repeatable step. We are applying that habit while revisiting TypeScript Narrowing.

Keep the example small enough to trace. First predict the normal result; then change one input and explain the boundary result in your own words.

TypeScript

let total = 0;
for (const value of [1, 2, 3]) {
  total += value;
}
console.log(total);

6

Try next: Use a shorter collection first, then add one value and trace the extra iteration aloud.

The core rule prepares a value, while the outer line decides how to show it. That keeps the result usable by a UI, test, API, or command-line caller. We are applying that habit while revisiting TypeScript Narrowing.

Keep the example small enough to trace. First predict the normal result; then change one input and explain the boundary result in your own words.

TypeScript

function display(value: string): string {
  return `Lesson: ${value}`;
}

console.log(display("TypeScript Narrowing"));

Lesson: TypeScript Narrowing

Try next: Change only the display text and verify that the underlying rule and result stay unchanged.

A useful example includes the nearest boundary, not only the happy path. We are making the behavior inspectable before a real caller relies on it. We are applying that habit while revisiting TypeScript Narrowing.

Keep the example small enough to trace. First predict the normal result; then change one input and explain the boundary result in your own words.

TypeScript

function quantity(value: number): number {
  if (value < 1) throw new Error("quantity must be positive");
  return value;
}

console.log(quantity(1));

1

Try next: Try the lowest supported value and then one value just outside the accepted range.

A compact assertion turns the lesson into a repeatable promise. It helps us catch a changed rule before a larger program hides the source of the mistake. We are applying that habit while revisiting TypeScript Narrowing.

Keep the example small enough to trace. First predict the normal result; then change one input and explain the boundary result in your own words.

TypeScript

const result: string = "TypeScript Narrowing".toUpperCase();
if (result !== "TYPESCRIPT NARROWING") throw new Error("contract failed");
console.log("contract holds");

contract holds

Try next: Deliberately change the expected value once, observe the failed check, and then restore the correct contract.

TypeScript Narrowing should make uncertainty visible instead of hiding it with casts. Name the input, trace the normal result, identify the boundary value, and decide which layer owns validation and failure behavior.

TypeScript protects compile-time relationships, but external JSON, browser input, environment values, and database rows still arrive at runtime. Validate those boundaries before a trusted domain function reads a property or makes a security decision.

• Run the normal input and record the exact observable result.
• Run an empty, malformed, or boundary input deliberately.
• Prefer a narrow union or result object over an unchecked cast.
• Keep mutation, I/O, and authorization at an explicit server-side boundary.
• Return a useful value or named failure a caller can test.

Professional TypeScript is readable under change: a future developer can locate the data contract, prove the normal path, and add one safe variant without reconstructing the entire module.

• Using as or any to silence a useful compiler warning instead of modelling the uncertainty.
• Treating a type annotation as proof that a request, environment value, or storage row has been validated.
• Publishing a wide type or class surface when a caller needs only one small capability.
• Copying an example without changing an input to verify the contract and expected failure.