TypeScript Strict Mode — Missing Null Check Broke Payments

JavaScript runs half the internet, but it has a well-known Achilles heel: it will happily let you pass a number where a string is expected, call a method on undefined, or silently return NaN and keep going. These bugs don't blow up at write-time — they blow up at 2am in production, after a user has already seen broken behaviour. That's not a flaw in your skill; it's a flaw in the language's design philosophy. JavaScript was built for small scripts, not 100,000-line enterprise applications.

TypeScript is Microsoft's answer to that problem. It's a strict superset of JavaScript — meaning every valid JS file is already valid TypeScript — that adds a static type system on top. The TypeScript compiler reads your types, checks your logic against them, then compiles everything down to plain JavaScript that any browser or Node.js process can run. The types vanish at runtime; they exist purely to protect you at development time. Think of them as scaffolding: essential while you're building, removed once the structure is sound.

By the end of this article you'll understand not just what TypeScript syntax looks like, but why the type system is designed the way it is, how to use interfaces and generics to model real-world data structures, and which mistakes will waste your time if you don't know about them upfront. You'll walk away ready to migrate a JavaScript project to TypeScript or start a new one with confidence.

What TypeScript Strict Mode Actually Enforces

TypeScript strict mode is a compiler flag that enables a set of type-checking rules designed to catch null safety and implicit any violations at compile time. It activates strictNullChecks, noImplicitAny, strictFunctionTypes, and others, turning the type system from a loose annotation layer into a sound null-safety guard. Without it, null and undefined are assignable to any type, which silently permits runtime null pointer exceptions in production.

When strict mode is on, every variable, parameter, and return type must explicitly account for null or undefined using union types like string | null. This forces developers to handle missing values at every boundary — function calls, API responses, database queries. The compiler rejects code paths where a nullable value is used without a check, effectively making null safety a compile-time guarantee rather than a runtime hope.

Use strict mode in every TypeScript project from day one. In payment systems, a missing null check on a transaction amount or user ID can cause silent failures, charge errors, or data corruption. Strict mode eliminates entire categories of bugs that slip into production, especially in data-intensive flows where null values are common. It's not optional — it's the baseline for any system that processes money or user data.

Static Typing vs Dynamic Typing — Why TypeScript Exists at All

In JavaScript every variable is dynamically typed — its type is determined at runtime based on the value it holds at that moment. That flexibility is useful for tiny scripts. But in a large codebase, it means you're constantly holding a mental model of what every variable 'should' be, because the language won't enforce it for you. Functions accept any argument, return values are ambiguous, and refactors become terrifying guessing games.

TypeScript introduces static typing: you declare what type a value is when you write the code, and the compiler verifies every usage before the code ever runs. If you write a function that expects a User object and you accidentally pass a plain string, TypeScript tells you immediately — right in your editor, with a red squiggle and a precise error message.

This isn't just about catching typos. It's about making your code self-documenting. A function signature like function sendEmail(recipient: User, subject: string): Promise<void> tells every developer on your team exactly what it needs and what it returns, with zero ambiguity. No more digging through documentation or console-logging to figure out what shape a value is. The types are the documentation.

// --- WITHOUT TypeScript (plain JavaScript behaviour) ---
// This function has no idea what 'user' looks like.
// Call it wrong and you get a silent runtime bug.
function greetUserJS(user) {
  // If 'user' is undefined, this crashes at runtime — not at write-time
  return `Hello, ${user.firstName}!`;
}

console.log(greetUserJS({ firstName: 'Alice' }));  // Hello, Alice!
console.log(greetUserJS(undefined));               // 💥 TypeError at runtime


// --- WITH TypeScript ---
// We define the exact shape a User must have.
interface User {
  firstName: string;
  lastName: string;
  email: string;
}

// The function now ONLY accepts a value that matches the User shape.
// TypeScript will refuse to compile if you pass anything else.
function greetUser(user: User): string {
  // 'user.firstName' is guaranteed to be a string — no null checks needed here
  return `Hello, ${user.firstName} ${user.lastName}!`;
}

const alice: User = {
  firstName: 'Alice',
  lastName: 'Nguyen',
  email: 'alice@example.com',
};

console.log(greetUser(alice)); // Hello, Alice Nguyen!

// Trying to call with wrong data — TypeScript catches this BEFORE you run the code:
// greetUser('Alice');  
// Error: Argument of type 'string' is not assignable to parameter of type 'User'

Interfaces and Type Aliases — Modelling Real-World Data Structures

Once you have more than a handful of typed variables, you need a way to describe the shape of complex objects — things like API responses, database records, or configuration objects. TypeScript gives you two tools for this: interface and type. They look similar and are often interchangeable, but they have meaningful differences worth understanding.

An interface is specifically designed to describe the shape of an object. It can be extended (like class inheritance), merged across multiple declarations, and implemented by a class. A type alias is more general — it can represent primitives, unions, intersections, tuples, and objects. If you're modelling an object that other parts of your code will implement or extend, reach for interface. If you need a union type or something more compositional, reach for type.

In a real project you'll use both. An API response might come back as User | null — that's a union, so type is appropriate. The User shape itself is a contract that components and services must honour — that's interface territory. Understanding when each tool is the right fit is what separates TypeScript beginners from developers who write genuinely maintainable typed code.

// --- INTERFACE: describes the shape of a product in our store ---
interface Product {
  id: number;
  name: string;
  priceInCents: number;   // storing price as integer cents avoids floating-point bugs
  inStock: boolean;
  tags: string[];         // an array of strings
}

// Interfaces can be extended — great for specialised variants
interface DigitalProduct extends Product {
  downloadUrl: string;    // only digital products have this field
  fileSizeMb: number;
}

// --- TYPE ALIAS: perfect for unions and computed types ---
// A cart item is a Product plus a quantity — intersection type
type CartItem = Product & {
  quantity: number;
};

// An API response is either data or an error — union type
type ApiResponse<T> = 
  | { success: true; data: T }        // happy path
  | { success: false; error: string }; // error path

// --- Real usage: a function that processes a cart ---
function calculateCartTotal(cartItems: CartItem[]): number {
  return cartItems.reduce((total, item) => {
    // TypeScript knows 'item.priceInCents' is a number — no coercion needed
    return total + item.priceInCents * item.quantity;
  }, 0);
}

const shoppingCart: CartItem[] = [
  { id: 1, name: 'Mechanical Keyboard', priceInCents: 12999, inStock: true, tags: ['hardware', 'peripherals'], quantity: 1 },
  { id: 2, name: 'USB-C Cable',         priceInCents: 1499,  inStock: true, tags: ['accessories'],            quantity: 3 },
];

const totalCents = calculateCartTotal(shoppingCart);
console.log(`Total: $${(totalCents / 100).toFixed(2)}`); // Total: $167.96

// --- ApiResponse in action ---
function handleProductFetch(response: ApiResponse<Product>): void {
  if (response.success) {
    // TypeScript NARROWS the type here — it knows 'response.data' exists
    console.log(`Fetched: ${response.data.name}`);
  } else {
    // Inside this branch TypeScript knows 'response.error' exists
    console.error(`Fetch failed: ${response.error}`);
  }
}

Interface vs Type: Detailed Comparison Matrix

While both interface and type can define object shapes, they have distinct capabilities and limitations that affect how you model data. Choosing the wrong one can lead to verbose code or unexpected behavior when refactoring. Here's a side-by-side comparison of their key features:

This table isn't just academic: choosing the wrong tool directly impacts compile-time error quality and maintainability. For production code where object shapes serve as shared contracts (e.g., API request/response models, database entities, component props), always start with interface. Reserve type for scenarios that demand unions, computed types, or primitive aliases. When you need both extension and union, consider splitting: define the base shape as an interface, then create union types from it.

// Example: When declaration merging matters (interface)
// Suppose you have multiple patches to a User type from different files:

// file1.ts
declare global {
  interface Window {
    appVersion: string;
  }
}

// file2.ts
declare global {
  interface Window {
    userLocale: string;
  }
}

// Both declarations merge — Window now has both properties
console.log(window.appVersion);  // OK
console.log(window.userLocale); // OK

// With type alias, this would be an error:
// type Window = { appVersion: string };
// type Window = { userLocale: string };  // ❌ Duplicate identifier 'Window'

// Example: Intersections vs extensions
interface Base {
  id: number;
}
interface Derived extends Base {
  name: string;
} // Easy to see inheritance

type BaseT = { id: number };
type DerivedT = BaseT & { name: string }; // Works, but chain can get messy

// Union type (type alias only)
type Status = 'active' | 'inactive' | 'pending';

Generics — Writing Code That Works for Any Type Without Losing Safety

Here's a problem you hit quickly in TypeScript: you want to write a reusable utility function — say, one that wraps an API response — but you don't want to lose type safety by falling back to any. If you type the parameter as any, TypeScript stops checking it and you've thrown away all the benefits you came here for.

Generics solve this elegantly. A generic is a type placeholder — a variable for a type rather than a value. You write the function once with a generic parameter like <T>, and TypeScript figures out what T actually is at each call site based on what you pass in. You get full type safety AND full reusability. It's one of the features that genuinely changes how you think about writing abstractions.

Generics show up everywhere in real TypeScript codebases: API client wrappers, data transformation utilities, React component props, custom hooks, and state management patterns. Once you're comfortable with them, you'll find yourself reaching for them constantly instead of duplicating code or compromising on any.

// A generic wrapper for fetch — works for ANY resource type
// 'T' is a placeholder that TypeScript fills in based on how you call this function
async function fetchResource<T>(url: string): Promise<ApiResponse<T>> {
  try {
    const response = await fetch(url);

    if (!response.ok) {
      // Return a typed error response
      return { success: false, error: `HTTP ${response.status}: ${response.statusText}` };
    }

    // TypeScript treats the parsed JSON as type T — we're asserting trust here
    const data = await response.json() as T;
    return { success: true, data };

  } catch (networkError) {
    return { success: false, error: 'Network request failed' };
  }
}

// --- Our domain types ---
interface BlogPost {
  id: number;
  title: string;
  body: string;
  authorId: number;
}

interface Comment {
  id: number;
  postId: number;
  text: string;
}

// --- Same function, different types — TypeScript tracks both ---
async function loadBlogData(): Promise<void> {
  // TypeScript infers 'result' as ApiResponse<BlogPost>
  const postResult = await fetchResource<BlogPost>(
    'https://jsonplaceholder.typicode.com/posts/1'
  );

  if (postResult.success) {
    // TypeScript KNOWS postResult.data is a BlogPost here
    // — so .title is valid, .nonExistentField would be a compile error
    console.log(`Post title: ${postResult.data.title}`);
  }

  // TypeScript infers 'commentResult' as ApiResponse<Comment>
  const commentResult = await fetchResource<Comment>(
    'https://jsonplaceholder.typicode.com/comments/1'
  );

  if (commentResult.success) {
    // TypeScript knows this is a Comment — .text is valid
    console.log(`First comment: ${commentResult.data.text.slice(0, 40)}...`);
  }
}

// --- A simpler generic utility to demonstrate the concept ---
// Takes any array, returns the first and last elements with full type safety
function getArrayBounds<T>(items: T[]): { first: T; last: T } | null {
  if (items.length === 0) return null;
  return {
    first: items[0],
    last: items[items.length - 1],
  };
}

const temperatures = [18.2, 22.7, 19.1, 25.3, 21.0];
const bounds = getArrayBounds(temperatures); // TypeScript infers T as number

if (bounds) {
  console.log(`Coldest recorded: ${bounds.first}°C`);
  console.log(`Most recent: ${bounds.last}°C`);
}

// TypeScript would flag this — you can't do .toFixed() on a string:
// const nameBounds = getArrayBounds(['Alice', 'Bob']);
// console.log(nameBounds?.first.toFixed(2)); // Error: Property 'toFixed' does not exist on type 'string'

Common Utility Types Cheat Sheet: Pick, Omit, Partial

TypeScript ships with several built-in utility types that save you from manually rewriting object shapes. The most frequently used in production code are Partial, Pick, and Omit. These are mapped types: they transform an existing type into a new type by adding or removing optionality or selecting specific keys. Understanding them is essential because they let you create derived types without duplicating interfaces, keeping your type definitions dry.

Partial<T> — makes every property in T optional. Use when you need to represent a partial update (e.g., PATCH request body) or a partially constructed object. Be careful: accessing a property that may now be undefined requires null checks.

Pick<T, K> — creates a type with only the specified keys K from T. Use when you want a subset of an interface, like a lightweight view of a user record that only includes name and email.

Omit<T, K> — creates a type with all keys from T except the specified keys K. Use when you want to exclude sensitive fields (e.g., password, ssn) from a response type, or when you need to remove a key before processing.

These utilities are the workhorses of real-world TypeScript projects. Combined with generics, they let you build type-safe data transformers, update functions, and API response filters with minimal boilerplate.

// Base interface used for all examples
interface User {
  id: number;
  name: string;
  email: string;
  password: string;
  role: 'admin' | 'user';
}

// ──────────────────────────────────────────────
// 1. Partial<User> → all properties become optional
// ──────────────────────────────────────────────
function updateUser(userId: number, changes: Partial<User>): void {
  // 'changes' can have any subset of User properties
  console.log(`Updating user ${userId} with:`, changes);
}

updateUser(1, { name: 'Alice' });          // OK
updateUser(1, { email: 'a@b.com', role: 'admin' }); // OK
updateUser(1, {});                         // OK — empty object is a valid Partial

// ──────────────────────────────────────────────
// 2. Pick<User, 'name' | 'email'> → only those keys
// ──────────────────────────────────────────────
type UserContact = Pick<User, 'name' | 'email'>;
// Equivalent to: { name: string; email: string }

function sendWelcomeEmail(contact: UserContact): void {
  console.log(`Sending email to ${contact.name} at ${contact.email}`);
}

sendWelcomeEmail({ name: 'Bob', email: 'bob@example.com' }); // OK
// sendWelcomeEmail({ name: 'Bob' }); // ❌ Property 'email' is missing

// ──────────────────────────────────────────────
// 3. Omit<User, 'password'> → all keys except 'password'
// ──────────────────────────────────────────────
type PublicUser = Omit<User, 'password'>;
// Equivalent to: { id: number; name: string; email: string; role: 'admin' | 'user' }

function getUserProfile(user: PublicUser): void {
  console.log(`${user.name} (${user.email}) - Role: ${user.role}`);
  // TypeScript does NOT allow access to user.password
}

// ──────────────────────────────────────────────
// Combining with generics: a reusable partial update handler
// ──────────────────────────────────────────────
async function patchResource<T>(
  url: string,
  changes: Partial<T>
): Promise<void> {
  await fetch(url, {
    method: 'PATCH',
    body: JSON.stringify(changes),
    headers: { 'Content-Type': 'application/json' },
  });
}

// Usage
await patchResource<User>('/api/users/1', { email: 'new@example.com' });
// TypeScript ensures you only pass valid keys of User

tsconfig.json — The Settings That Make TypeScript Actually Strict

Installing TypeScript and adding a few type annotations doesn't automatically make your code safe. TypeScript has a spectrum of strictness controlled by tsconfig.json, and the default settings are surprisingly permissive. The most important flag is strict: true — it's actually a shorthand that enables a bundle of individual checks, the most consequential being strictNullChecks.

Without strictNullChecks, TypeScript allows null and undefined to be assigned to any type. That means a variable typed as string could actually be null at runtime, and TypeScript won't complain. With it enabled, null and undefined become their own distinct types. A function that might return nothing must say so explicitly with a return type like string | null, and every caller must handle that null case. This is uncomfortable at first and absolutely worth it.

Other key flags: noImplicitAny prevents TypeScript from silently falling back to any when it can't infer a type — you're forced to be explicit. noUnusedLocals keeps your codebase clean. target and module control what JavaScript version TypeScript compiles down to. Starting a new project? Set strict: true from day one. Migrating an existing project? Enable flags incrementally to avoid being overwhelmed.

{
  "compilerOptions": {
    // What version of JavaScript to compile DOWN to
    // 'ES2020' supports async/await, optional chaining, etc.
    "target": "ES2020",

    // Module system — use 'NodeNext' for Node.js, 'ESNext' for bundlers
    "module": "NodeNext",
    "moduleResolution": "NodeNext",

    // Where compiled .js files go — keep them separate from your source
    "outDir": "./dist",

    // Where TypeScript looks for your source files
    "rootDir": "./src",

    // ✅ THE MOST IMPORTANT FLAG — enables all strict checks at once
    // This includes: strictNullChecks, noImplicitAny, strictFunctionTypes, etc.
    "strict": true,

    // Errors if you declare a variable and never use it
    // Keeps your codebase clean during refactors
    "noUnusedLocals": true,

    // Errors if a function parameter is declared but never used
    "noUnusedParameters": true,

    // Errors if a code path in a function doesn't return a value
    // Catches missing return statements in switch/if branches
    "noImplicitReturns": true,

    // Allows importing .json files as typed modules
    "resolveJsonModule": true,

    // Enables source maps so debuggers show your .ts files, not compiled .js
    "sourceMap": true,

    // Allows TypeScript to understand ES modules alongside CommonJS
    "esModuleInterop": true
  },
  "include": ["src/**/*"],
  "exclude": ["node_modules", "dist", "**/*.test.ts"]
}

Essential tsconfig.json Flags: strict, noImplicitAny, and More

While the previous section explained the strict mode philosophy, this is your quick reference for the most important compiler flags you need to know for production TypeScript. Every flag here has a direct impact on the safety and maintainability of your codebase.

For new projects, set strict: true and never look back. For migrations, start with noImplicitAny and strictNullChecks. Once those compile clean, turn on strictFunctionTypes. The table above serves as a checklist you can paste into your pull request template as a config review reminder.

{
  "compilerOptions": {
    "target": "ES2020",
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "outDir": "./dist",
    "rootDir": "./src",
    "strict": true,                          // All flags below are now on
    // Individual flags (can be toggled off during migration)
    "strictNullChecks": true,                // Already enabled by strict
    "noImplicitAny": true,                   // Already enabled by strict
    "strictFunctionTypes": true,             // Already enabled by strict
    "noUnusedLocals": true,                  // Not part of strict, add manually
    "noUnusedParameters": true,              // Not part of strict, add manually
    "noImplicitReturns": true,               // Not part of strict, add manually
    "exactOptionalPropertyTypes": false,     // Advanced, enable after migration
    "resolveJsonModule": true,
    "esModuleInterop": true,
    "sourceMap": true
  },
  "include": ["src"],
  "exclude": ["node_modules", "dist"]
}

Type Narrowing and Type Guards — Writing Code That Handles Multiple Types Safely

Once you start using union types (e.g., string | null, Success | Failure), you'll hit a wall: TypeScript won't let you access properties or call methods that only exist on one branch of the union. You need to narrow the type before you can use it. Type narrowing is the process of refining a broad type into a more specific one based on runtime checks.

TypeScript understands common JavaScript patterns as type guards: typeof, instanceof, in, equality checks, and user-defined predicates. When you write if (typeof value === 'string'), TypeScript knows that inside that if block, value is a string — and it can safely let you call .toLowerCase(). Outside the if, it's still the union type.

User-defined type guards are a powerful pattern for complex checks. A function that returns a predicate like value is string tells TypeScript that when the function returns true, the argument is that specific type. This is invaluable for validating API responses, discriminating unions, and parsing untrusted data.

// --- Using typeof and truthiness checks ---
function printLength(value: string | null): void {
  if (value) {
    // Inside this block, 'value' is automatically narrowed to 'string'
    // TypeScript knows null and undefined are falsy
    console.log(value.length);
  } else {
    console.log('No value provided');
  }
}

// --- Using instanceof for class instances ---
class Order {
  constructor(public id: number, public total: number) {}
}

class Refund {
  constructor(public orderId: number, public amount: number, public reason: string) {}
}

type Transaction = Order | Refund;

function processTransaction(tx: Transaction): void {
  if (tx instanceof Order) {
    // TypeScript knows tx is Order here
    console.log(`Order #${tx.id}: $${(tx.total / 100).toFixed(2)}`);
  } else {
    // TypeScript knows tx is Refund here
    console.log(`Refund for order #${tx.orderId}: ${tx.reason}`);
  }
}

// --- User-defined type guard ---
interface ApiError {
  errorCode: number;
  message: string;
}

interface ApiSuccess<T> {
  data: T;
}

// A custom type guard function
function isApiError<T>(response: ApiError | ApiSuccess<T>): response is ApiError {
  return 'errorCode' in response;
}

function handleApiResponse<T>(response: ApiError | ApiSuccess<T>): void {
  if (isApiError(response)) {
    // Inside this block, TypeScript knows response is ApiError
    // and we can safely access errorCode and message
    console.error(`Error ${response.errorCode}: ${response.message}`);
    // If we tried to access response.data, TypeScript would error
  } else {
    // Response is ApiSuccess<T>
    console.log('Data received:', response.data);
  }
}

Why Your Codebase Is Still Full of `any` — And How to Kill It for Good

You know the drill. Some junior—or let's be honest, probably you at 2 AM—slaps as any on a response from an API and calls it a day. That any doesn't just turn off type checking. It erases the entire contract between your code and the data it processes. When that API shape changes next sprint, you don't get a compile-time error. You get a Cannot read properties of undefined in production at 3 PM on a Friday.

The fix isn't just 'use strict mode.' You need a zero-tolerance policy for implicit any in function returns. TypeScript's noImplicitReturns flag catches functions that forget to return a value. But the real weapon is strictNullChecks combined with noUncheckedIndexedAccess. That combo forces you to handle every undefined branch explicitly. No more optional chaining as a crutch—you actually check the thing exists before you touch it.

Here's the pattern that senior teams enforce: every function has an explicit return type. If you see a function without one, that's a code review fail. Period. When you type the return, the compiler catches mistakes you didn't even know you made. And when you're consuming external data, use a runtime validator like Zod or io-ts to bridge the gap between the wild west of JSON and your typed world. TypeScript doesn't run at runtime—your validators do.

// io.thecodeforge — javascript tutorial

// The problem: implicit return types hide broken contracts
function fetchUser(id: string) {
  const raw = fetch(`/users/${id}`).then(r => r.json());
  return raw; // type is Promise<any>
}

// The fix: explicit return type + runtime validation
import { z } from 'zod';

const UserSchema = z.object({
  id: z.string().uuid(),
  name: z.string().min(1),
  email: z.string().email(),
  role: z.enum(['admin', 'user', 'viewer'])
});

async function fetchUserSafe(id: string): Promise<z.infer<typeof UserSchema>> {
  const raw = await fetch(`/users/${id}`).then(r => r.json());
  const parsed = UserSchema.safeParse(raw);
  
  if (!parsed.success) {
    throw new Error(`User fetch failed validation: ${parsed.error.message}`);
  }
  
  return parsed.data; // fully typed, null-free
}

The Union Type Trick That Prevents Invalid States at Compile Time

Most devs think union types are just for 'string or number.' That's like using a scalpel to open a can of beans. The real power of union types is modelling mutually exclusive states so the compiler eliminates entire classes of bugs before they compile.

Consider a form that can be in three states: idle, submitting, or error. The naive approach is three booleans: isIdle, isSubmitting, isError. But booleans are a liar's data type—they let you represent states that don't make sense, like isIdle=true and isSubmitting=true simultaneously. That's a bug that lives in the gap between what you intend and what the type system allows.

Instead, model the state as a discriminated union. Each variant carries only the data relevant to that state. When you're in 'submitting', there's no error message field. When you're in 'error', there's no result data. The compiler enforces this—not your code review, not your tests, not your prayers. This pattern is called 'making illegal states unrepresentable.' It's not buzzword fluff—it's the difference between a codebase you trust and one you're scared to deploy on a Friday.

Apply this to API responses, UI states, navigation stacks—anywhere you'd reach for an enum or a set of flags. Your type definitions become executable documentation that the compiler enforces.

// io.thecodeforge — javascript tutorial

// The wrong way: three booleans that lie to you
interface BadFormState {
  isIdle: boolean;
  isSubmitting: boolean;
  isError: boolean;
  errorMessage?: string;
  result?: PaymentData;
}
// Bug: { isIdle: true, isSubmitting: true, isError: false } — compiles fine

// The right way: discriminated union of valid states
type PaymentFormState =
  | { status: 'idle' }
  | { status: 'submitting'; paymentId: string }
  | { status: 'succeeded'; transaction: TransactionReceipt }
  | { status: 'failed'; errorCode: number; errorMessage: string };

function renderForm(state: PaymentFormState) {
  switch (state.status) {
    case 'idle':
      return '<button>Pay Now</button>';
    case 'submitting':
      return `<spinner /> Processing payment ${state.paymentId}`;
    case 'succeeded':
      return `<Receipt ${state.transaction.amount} />`; // safe access
    case 'failed':
      return `<ErrorBanner code=${state.errorCode} />`; // only error fields here
  }
}

Classes Are Not Your Dump Truck — When OOP Actually Pays Off in TypeScript

TypeScript classes aren't Java. You don't need a class for every noun in your domain model. The real value of classes in TypeScript is encapsulation of state with guaranteed invariants, not inheritance pyramids that collapse in month two.

Use classes when you have mutable state that must stay consistent — a bank account that can't go negative, a WebSocket connection manager that enforces a max reconnection count. For data-only structures, interfaces or type aliases are cheaper and easier to reason about. The private, protected, and readonly modifiers exist so you can enforce constraints from the constructor onward, not so you can write getters for every field.

The implements keyword is your friend. Code against interfaces, not concrete classes. That way you can swap implementations without touching callers. And please, stop putting business logic in constructors. Build objects with factory functions or static methods, keep constructors simple assignments.

// io.thecodeforge — javascript tutorial

interface Account {
  readonly id: string;
  balance: number;
  deposit(amount: number): void;
}

class CheckingAccount implements Account {
  readonly id: string;
  private _balance: number = 0;

  constructor(id: string, initial: number) {
    if (initial < 0) throw new Error('Negative initial balance');
    this.id = id;
    this._balance = initial;
  }

  get balance(): number {
    return this._balance;
  }

  deposit(amount: number): void {
    if (amount <= 0) throw new Error('Deposit must be positive');
    this._balance += amount;
  }
}

const acct = new CheckingAccount('acct-1', 100);
acct.deposit(50);
console.log(acct.balance);

Testing TypeScript Means Testing The Types, Not Just The Values

Your test suite should fail when types break before a single runtime assertion runs. Unit tests prove your logic works for given inputs. Type tests prove your generics, unions, and overloads actually constrain callers correctly.

Use @ts-expect-error in tests — place it on lines you expect to be type errors. If the line compiles without error, the test fails. This catches API contract violations during CI. For example, if you change a function signature, the type test that passed a string where a number was expected will now fail to compile, and your type-level test pinpoints exactly which callers broke.

For runtime testing, pick Vitest over Jest. It's faster, uses the same describe/it/expect API you already know, and handles TypeScript and ESM natively without babel acrobatics. Mock minimally — if your module is hard to test without mocking, your module is coupled wrong, not your test framework.

Production rule: a PR that changes types without adding a type test is incomplete. Period.

// io.thecodeforge — javascript tutorial

import { expect, test } from 'vitest';

type ExtractString<T> = T extends string ? T : never;

// Runtime test: logic works
function identity<T>(x: T): T {
  return x;
}

test('identity returns same value', () => {
  expect(identity(42)).toBe(42);
});

// Type test: contract is correct
// @ts-expect-error — number should be blocked
type Result = ExtractString<42>;

// @ts-expect-error — number should be blocked
type Result2 = ExtractString<true>;

// This should compile clean
type Result3 = ExtractString<'hello'>;

Classes Aren’t a Silver Bullet — When OOP Actually Pays Off in TypeScript

TypeScript classes exist for when you need encapsulated state that changes over time — a bank account, a game character, a WebSocket connection. If your data is just a blob of fields, use an interface or type alias. Classes add runtime cost, constructor boilerplate, and prototypal inheritance complexity. Reach for a class when you need methods that mutate internal state, when you want to enforce invariants via private fields, or when you rely on instanceof type guards. For pure data transfer objects, interfaces with factory functions are lighter and compose better. The trap: using classes everywhere because you came from Java or C#. That kills TypeScript’s structural typing advantages. Reserve classes for objects with behavior that must stay coupled to mutable state. Everything else stays plain objects with functions.

// io.thecodeforge — javascript tutorial

// Bad: class for static data
class User {
  constructor(public name: string) {}
}

// Good: interface for data, function for behavior
interface User {
  name: string;
}
const greet = (u: User) => `Hello ${u.name}`;

// Good: class for mutable state with invariants
class Wallet {
  private balance = 0;
  deposit(amount: number) {
    if (amount <= 0) throw new Error('Invalid');
    this.balance += amount;
  }
}

TypeScript Interview Questions That Test Real Understanding

Interviewers love asking about keyof, conditional types, and the infer keyword — because those reveal whether you truly grasp TypeScript’s type system or just skate by with any. Expect: "How does typeof differ in TypeScript vs JavaScript?" (JS: runtime string tag; TS: compile-time type query). "What does extends do in generics vs classes?" (Generics: constraint; Classes: inheritance). "Write a type that extracts the return type from a function." (Use infer R in a conditional type). The real test: explain why Pick<T, K> is safer than Omit<T, K> when K is a union (Pick fails at compile-time if K has an invalid member; Omit silently returns T). Another classic: "How do discriminated unions prevent invalid states?" Show a union of objects with a kind literal field, then switch on it — TypeScript narrows the payload per case. Master these patterns, and you’ll pass any senior-level TypeScript screen.

// io.thecodeforge — javascript tutorial

// Discriminated union — golden interview answer
type Shape =
  | { kind: 'circle'; radius: number }
  | { kind: 'rect'; w: number; h: number };

const area = (s: Shape) =>
  s.kind === 'circle'
    ? Math.PI * s.radius ** 2  // s is narrowed
    : s.w * s.h;

// Conditional type with infer
type ReturnOf<T> =
  T extends (...args: any[]) => infer R ? R : never;

// Usage
type Fn = (x: string) => number;
type R = ReturnOf<Fn>;  // number