TypeScript

TypeScript is a superset of JavaScript that adds static types. In simple language, it’s plain JS plus a type-checker that runs at build time. When we compile, TypeScript strips all the types away and gives us regular JavaScript that runs in any browser or Node.js.

So why bother? JS is dynamically typed — variables can hold anything, and we only find out we passed a string where a number was expected at runtime (usually in production at 2 AM). TS catches those mistakes while we type the code.

The three big wins:

• Catch bugs early. Typos, wrong argument types, missing properties — flagged before we run anything.
• Editor superpowers. Autocomplete actually knows what user. can be. Refactors (rename a field) update every usage.
• Self-documenting code. Types describe intent — we don’t need to read the function body to know what it returns.

Think of it like wearing a seatbelt. It doesn’t make us a better driver, but it prevents the silly accidents from being catastrophic.

// Plain JS — this compiles fine and crashes at runtime
function greet(name) {
  return "Hello, " + name.toUpperCase();
}
greet(42); // 💥 name.toUpperCase is not a function

// TypeScript — caught at compile time
function greetTs(name: string): string {
  return "Hello, " + name.toUpperCase();
}
greetTs(42); // ❌ Argument of type 'number' is not assignable to 'string'

The only difference is the : string annotations. That tiny addition gives us the safety.

How it actually runs

TS code never runs directly. The TypeScript compiler (tsc) checks types, then emits JS. Tools like ts-node, tsx, Vite, and Next.js wrap this so we don’t think about it.

npm install -D typescript
npx tsc --init   # creates tsconfig.json
npx tsc          # compiles .ts → .js

When NOT to use it

For tiny throwaway scripts or a 10-line demo, TS is overkill. But anything with a team, anything that ships to users, anything we’ll touch again in 6 months — types pay for themselves quickly.

Interview soundbite

“TypeScript is a static type-checker layered on JavaScript. Types exist at compile time only — the runtime is just JS. We get earlier bug detection and much better tooling, at the cost of a build step and a learning curve.”

TypeScript ships with a small set of primitive types that cover almost everything we write. Let’s walk through them.

The familiar three

string, number, boolean — exactly what they sound like. No separate int or float in TS; everything is number (just like JS).

const name: string = "Manish";
const age: number = 27;       // ints and floats both
const isAdmin: boolean = true;

null and undefined

Two ways JS says “nothing here”. In simple language, undefined means “not assigned yet” and null means “explicitly empty”. With strictNullChecks on (which we always want), these are NOT assignable to other types.

let maybe: string | null = null;
maybe = "hello"; // fine
let nope: string = null; // ❌ error with strict mode

any — the escape hatch

any turns off type-checking for that value. It’s like writing plain JS. Useful while migrating a codebase, dangerous everywhere else.

let yolo: any = 5;
yolo.foo.bar.baz(); // no error — and a runtime explosion waiting to happen

Rule of thumb: if we’re reaching for any, we’re probably looking for unknown.

unknown — the safe any

unknown says “I don’t know what this is, and TS will force me to check before using it”. It’s the type-safe version of any.

function parse(input: unknown) {
  // input.toUpperCase(); // ❌ can't use it directly
  if (typeof input === "string") {
    return input.toUpperCase(); // ✅ narrowed to string
  }
}

void — function returns nothing

Used for functions that don’t return a value. Different from undefined — void says “the return value should be ignored”.

function logIt(msg: string): void {
  console.log(msg);
  // no return statement
}

never — this can never happen

never is the type of things that never produce a value. Functions that always throw, or infinite loops. It’s also what we get when a union is fully narrowed away.

function fail(msg: string): never {
  throw new Error(msg); // never returns
}

never shows up a lot in exhaustive switch checks — see the Discriminated Unions note.

Quick reference

const a: string = "x";
const b: number = 1;
const c: boolean = true;
const d: null = null;
const e: undefined = undefined;
const f: any = "anything";      // avoid
const g: unknown = "anything";  // prefer over any
function h(): void {}
function i(): never { throw new Error(); }

Interview soundbite

“any skips the check, unknown forces a check. void is for functions returning nothing, never is for functions that can’t return at all (they throw or loop forever).”

There are two ways TypeScript learns about types: we tell it (annotations) or it figures it out from the code (inference). Knowing when to use each keeps our code clean.

Annotations — we declare the type

We add : Type after a variable, parameter, or return.

const name: string = "Manish";
function add(a: number, b: number): number {
  return a + b;
}

Inference — TS reads our code

If we initialize a variable, TS already knows its type. We don’t need to repeat ourselves.

const name = "Manish";  // inferred as string
const age = 27;         // inferred as number
const user = { id: 1, email: "x@y.com" }; // inferred as { id: number; email: string }

In simple language, if it’s obvious from the value, just don’t annotate.

The rule of thumb

• Annotate at the boundaries — function parameters, function return types (for public APIs), and exported values.
• Let inference handle the inside — local variables, intermediate expressions.

// ✅ Good — annotate inputs/outputs, infer locals
function calculateTotal(items: number[]): number {
  const sum = items.reduce((acc, n) => acc + n, 0); // 'sum' inferred as number
  const tax = sum * 0.18;                            // inferred
  return sum + tax;
}

// ❌ Noisy — over-annotated
function calculateTotalBad(items: number[]): number {
  const sum: number = items.reduce((acc: number, n: number) => acc + n, 0);
  const tax: number = sum * 0.18;
  return sum + tax;
}

Why annotate function returns?

Even when TS can infer the return type, writing it down has two benefits:

1. Catches bugs at the source. If we accidentally return the wrong thing, the error shows up in the function, not at every call site.
2. It’s a contract. Other devs see the signature without reading the body.

function getUser(id: number): { id: number; name: string } {
  // if we accidentally return null here, error is HERE not at the caller
  return { id, name: "Manish" };
}

The let vs const widening gotcha

const of a literal infers the literal type. let widens to the primitive.

const direction = "left";  // type is "left" (literal)
let dir = "left";          // type is string (widened)

This matters when assigning to typed slots — see the Literal Types note.

Inference for arrays and objects

Empty arrays are inferred as any[] — usually a mistake. Annotate when starting empty.

const nums = [];          // any[] — bad
const nums2: number[] = []; // number[] — good

Interview soundbite

“Let inference do the work. Annotate at the boundaries — function params, return types, public APIs. Avoid over-annotating locals; it’s just noise that has to be maintained.”

Lists in TypeScript come in three flavors. Most code uses regular arrays, but tuples and readonly arrays solve real problems too.

Arrays — variable length, one type

Two equivalent syntaxes. Use whichever you prefer (T[] is more common).

const nums: number[] = [1, 2, 3];
const names: Array<string> = ["a", "b"];

nums.push(4);   // ✅
nums.push("5"); // ❌ string not assignable to number

Tuples — fixed length, fixed types per position

A tuple is an array where each index has its own type and the length is known. Think of it like an unnamed record.

type RGB = [number, number, number];
const red: RGB = [255, 0, 0];

const pair: [string, number] = ["age", 27];
// pair[0] is string, pair[1] is number

The classic use case: returning multiple values from a function (like React’s useState).

function useCounter(initial: number): [number, () => void] {
  let count = initial;
  const inc = () => { count++; };
  return [count, inc];
}

const [count, increment] = useCounter(0);

Labeled tuples — better readability

We can name each slot for documentation. Labels don’t affect the type, just IDE hints.

type Range = [start: number, end: number];
const r: Range = [0, 10]; // hovering shows 'start' and 'end'

Optional and rest in tuples

type Optional = [string, number?];           // second item is optional
type Rest = [string, ...number[]];           // string followed by any number of numbers

const a: Optional = ["x"];      // ✅
const b: Rest = ["tag", 1, 2, 3]; // ✅

readonly arrays — can’t mutate

Adding readonly (or using ReadonlyArray<T>) blocks push, pop, splice, index assignment — anything that mutates.

const fixed: readonly number[] = [1, 2, 3];
fixed.push(4);   // ❌ Property 'push' does not exist on readonly number[]
fixed[0] = 99;   // ❌ Index signature is readonly

Why bother? Function parameters mostly. We signal that we won’t mutate the caller’s array.

function sum(nums: readonly number[]): number {
  // can't accidentally modify nums here
  return nums.reduce((a, b) => a + b, 0);
}

readonly tuples

const point: readonly [number, number] = [1, 2];
point[0] = 5; // ❌

as const — make everything readonly literally

Slapping as const at the end gives us a deeply readonly tuple of literals. Great for constants.

const directions = ["up", "down", "left", "right"] as const;
// type: readonly ["up", "down", "left", "right"]

type Direction = typeof directions[number]; // "up" | "down" | "left" | "right"

When to use which

• Array T[] — most code. Lists of homogeneous things.
• Tuple [A, B] — multiple return values, fixed pairs (coordinates, key-value).
• readonly — parameters we shouldn’t mutate, public constants.
• as const — derive a union of string literals from an array.

Interview soundbite

“Arrays are homogeneous and variable-length. Tuples are fixed-length with per-position types — great for returning multiple values. readonly prevents mutation, useful for function parameters and shared constants.”

Enums let us define a named set of constants. In simple language, instead of remembering that 0 means “pending” and 1 means “approved”, we write Status.Pending and Status.Approved.

Enums are the one TypeScript feature that’s NOT just a type — they emit real JavaScript at runtime. That’s both a feature and a footgun.

Numeric enums (default)

Members get auto-incremented numbers starting from 0.

enum Status {
  Pending,    // 0
  Approved,   // 1
  Rejected,   // 2
}

const s: Status = Status.Approved;
console.log(s); // 1

We can set the starting number — the rest auto-increment.

enum HttpCode {
  OK = 200,
  Created,        // 201
  BadRequest = 400,
  Unauthorized,   // 401
}

Numeric enums also create a reverse mapping. Status[1] gives "Approved". That’s why they emit more JS than expected.

String enums

Every member needs an explicit string value. No reverse mapping, but the values are human-readable in logs and DBs.

enum Direction {
  Up = "UP",
  Down = "DOWN",
  Left = "LEFT",
  Right = "RIGHT",
}

const d: Direction = Direction.Up;
console.log(d); // "UP"

String enums are the safest enum — what you see is what you get.

Const enums — zero runtime cost

A regular enum compiles to a JS object. A const enum is inlined at compile time — the enum object disappears entirely.

const enum Color {
  Red,
  Green,
  Blue,
}

const c = Color.Red;
// compiles to:  const c = 0 /* Color.Red */;

No runtime object, faster, smaller bundles. The catch: const enums don’t play well with isolated modules (Babel, esbuild, isolatedModules: true). Many setups disable them.

Why people avoid enums

Three reasons enums get a bad rap:

1. Numeric enums aren’t type-safe. Any number is assignable to a numeric enum slot.
2. They emit runtime code. Bigger bundles, weird-looking compiled output.
3. const enum is brittle. Doesn’t work in all toolchains.

The modern alternative is a union of string literals plus as const:

// Union of literals — no runtime cost, fully type-safe
type Status = "pending" | "approved" | "rejected";
const s: Status = "approved";

// Or, derived from a const object
const Status = {
  Pending: "pending",
  Approved: "approved",
  Rejected: "rejected",
} as const;
type StatusValue = typeof Status[keyof typeof Status];

The only difference is that we don’t get the Status.Pending namespace lookup — but "pending" is just as readable, and we save the JS emit.

When to actually use enums

• String enums for shared values across services where readability in logs/DB matters.
• Avoid numeric enums unless interfacing with code that uses numeric flags.
• Avoid const enums unless you control the whole build pipeline.

Interview soundbite

“Enums emit runtime code, unlike most TS features. String enums are safe, numeric enums have a reverse mapping but aren’t strictly typed, const enums get inlined but don’t work with all bundlers. Many teams prefer union-of-literals plus as const instead.”

This is THE TypeScript interview question. The honest answer: 90% of the time they’re interchangeable for object shapes, but the 10% matters.

In simple language — interface is built for describing the shape of an object. type is more flexible and can describe anything: objects, unions, primitives, tuples, function signatures.

What they have in common

Both describe object shapes. Both work with classes via implements. Both work with generics.

// Interface
interface User {
  id: number;
  name: string;
}

// Type alias — same job
type UserT = {
  id: number;
  name: string;
};

Where they differ

Declaration merging — interface only

Declare an interface twice and TS merges them. This is powerful for extending third-party types (e.g., adding properties to Window).

interface User { id: number; }
interface User { name: string; }

const u: User = { id: 1, name: "Manish" }; // both required ✅

With type, this is an error — types can’t be redeclared.

type UserT = { id: number; };
type UserT = { name: string; }; // ❌ Duplicate identifier

Unions — type only

type can describe anything; interface can only describe an object shape.

type ID = string | number;            // ✅ type can
type Result = { ok: true } | { ok: false; error: string };

// interface ID = string | number;    // ❌ syntax error

Extending

Both can extend, just with different syntax.

// Interface extends interface
interface Animal { name: string; }
interface Dog extends Animal { breed: string; }

// Type uses intersection
type AnimalT = { name: string; };
type DogT = AnimalT & { breed: string; };

Implements (with classes)

Both work, no real difference here.

interface Logger { log(msg: string): void; }
class ConsoleLogger implements Logger {
  log(msg: string) { console.log(msg); }
}

The practical rule

• Use interface for object shapes that are part of a public API. Declaration merging is a nice escape hatch.
• Use type when you need unions, intersections, tuples, mapped types, or conditional types.
• Be consistent within a codebase. Pick a default and stick with it.

A common convention: interface for object shapes, type for everything else.

Performance note

For very large unions, interface (with extends) is slightly faster for the compiler than type with intersection. Mostly irrelevant unless you’re typing thousands of objects.

Interview soundbite

“For plain object shapes they’re nearly identical. The differences: interface supports declaration merging and only describes objects; type is a general alias that can describe unions, primitives, tuples, and mapped types. Use interface for public object APIs, type for everything else.”

Two operators sit at the heart of TypeScript’s type system: | (union) and & (intersection). They look like JS bitwise operators but mean something very different here.

Union — A | B means “either A or B”

A value of type A | B could be either. We can only use properties/methods that exist on BOTH sides until we narrow.

type ID = string | number;

function printId(id: ID) {
  // id.toUpperCase(); // ❌ not all IDs have this
  if (typeof id === "string") {
    console.log(id.toUpperCase()); // ✅ narrowed to string
  } else {
    console.log(id.toFixed(2));    // ✅ narrowed to number
  }
}

Unions are everywhere — function parameters that accept multiple shapes, return types that can be a value or null, state machines.

type LoadState = "idle" | "loading" | "success" | "error";

Intersection — A & B means “both A and B at once”

A value of type A & B has ALL properties from both. Think of it as merging the shapes.

type HasId = { id: number };
type HasName = { name: string };

type User = HasId & HasName;
// User has both id AND name

const u: User = { id: 1, name: "Manish" }; // both required

In simple language — union narrows what we can do (only common stuff), intersection broadens what we have (everything from both).

Combining unions and intersections

Real-world types often mix both. A common pattern is “base props + variant”.

type ButtonBase = { onClick: () => void };
type Primary = { variant: "primary"; label: string };
type Icon = { variant: "icon"; icon: string };

type ButtonProps = ButtonBase & (Primary | Icon);
// every button has onClick, plus EITHER label OR icon depending on variant

Intersection of primitives — never

Intersecting incompatible primitives gives never (no value can be both).

type Weird = string & number; // never

Common mistake: union of objects ≠ intersection of properties

When we have A | B where both are objects, we can only access properties present in BOTH.

type A = { x: number; y: number };
type B = { x: number; z: number };

function f(v: A | B) {
  v.x; // ✅ in both
  // v.y; // ❌ only in A
}

That’s where discriminated unions come in — they let us narrow cleanly. See the next note.

Narrowing unions

We narrow with typeof, instanceof, in, equality checks, or user-defined type guards. See the Type Narrowing note for the full story.

function area(shape: { kind: "circle"; r: number } | { kind: "square"; s: number }) {
  if (shape.kind === "circle") return Math.PI * shape.r ** 2;
  return shape.s ** 2;
}

Interview soundbite

“| is union, an OR — value is one of the listed types and we narrow before using specifics. & is intersection, an AND — value has everything from both types. Unions need narrowing; intersections combine shapes.”

A literal type is a type that has exactly one possible value. Instead of string, it could be the literal "left". Instead of number, the literal 42. Combine them with unions and we get the safest, most expressive APIs in TS.

What’s a literal type?

let dir: "left" | "right" | "up" | "down";
dir = "left";   // ✅
dir = "north";  // ❌ Type '"north"' is not assignable

In simple language, we’re saying “this variable can only hold one of these exact strings”. It’s a closed set — and TS will flag any typo.

The widening problem

Here’s the catch. const of a literal keeps the literal type, but let widens to the primitive.

const a = "left";  // type: "left" (literal)
let b = "left";    // type: string  (widened)

const dir: "left" | "right" = a; // ✅
const dir2: "left" | "right" = b; // ❌ string not assignable

Same thing happens with object properties — they widen by default.

const config = { mode: "dark" }; // mode is string, not "dark"

type Theme = { mode: "light" | "dark" };
const t: Theme = config; // ❌

This is where as const saves us.

as const — the const assertion

Adding as const tells TS: “treat this exactly as written — don’t widen anything, make every property readonly, treat strings/numbers as literals”.

const config = { mode: "dark" } as const;
// type: { readonly mode: "dark" }

const t: Theme = config; // ✅

Deriving types from data

This is the killer use case. Define data once, derive types from it.

const STATUSES = ["pending", "approved", "rejected"] as const;
// type: readonly ["pending", "approved", "rejected"]

type Status = typeof STATUSES[number];
// type: "pending" | "approved" | "rejected"

We just got a string-literal union from an array, without duplicating values. Add a new status to the array and the type updates automatically.

const ROUTES = {
  home: "/",
  profile: "/profile",
  settings: "/settings",
} as const;

type RoutePath = typeof ROUTES[keyof typeof ROUTES];
// type: "/" | "/profile" | "/settings"

Numeric and boolean literals

Not just strings — numbers and booleans can be literals too.

type DiceRoll = 1 | 2 | 3 | 4 | 5 | 6;
type Coin = "heads" | "tails";
type Toggle = true | false; // same as boolean

function roll(): DiceRoll {
  return (Math.floor(Math.random() * 6) + 1) as DiceRoll;
}

Literal types as function returns

A function returning a literal lets callers branch precisely.

function getEnv(): "dev" | "prod" {
  return process.env.NODE_ENV === "production" ? "prod" : "dev";
}

Combining with discriminated unions

Literals on a shared kind field are how discriminated unions work — see the next note.

type Shape =
  | { kind: "circle"; radius: number }
  | { kind: "square"; size: number };

Common gotcha: passing object literals to typed slots

type Btn = { variant: "primary" | "secondary" };

const a = { variant: "primary" };
const btn: Btn = a; // ❌ a.variant is string, not "primary"

const c = { variant: "primary" } as const;
const btn2: Btn = c; // ✅

Interview soundbite

“A literal type is a type with one possible value, like the string 'left' rather than all of string. Combined with unions they make tight, typo-proof APIs. as const stops widening — keeps literals literal and makes objects/arrays deeply readonly. Together they let us derive types from runtime data.”

A type alias is just a name for a type. In simple language, instead of repeating { id: number; name: string } everywhere, we name it User once and reference it.

The basics

type ID = string | number;
type User = {
  id: ID;
  name: string;
  email: string;
};

const u: User = { id: 1, name: "Manish", email: "x@y.com" };

That’s it. The type keyword followed by a name and an =. Anything to the right of = can be a type expression — primitives, objects, unions, tuples, functions, anything.

Aliasing primitives

Useful when a primitive carries domain meaning.

type Email = string;
type UserId = number;
type Timestamp = number;

function notify(to: Email, at: Timestamp): void { /* ... */ }

Note: this doesn’t make Email a distinct type from string — it’s just a label. Any string will work where Email is expected. For nominal typing (truly distinct types) we need a “branded type” pattern. That’s an advanced topic.

Aliasing function signatures

type Predicate<T> = (value: T) => boolean;

const isEven: Predicate<number> = (n) => n % 2 === 0;
const isShort: Predicate<string> = (s) => s.length < 5;

Aliasing unions

This is where aliases really pay off — naming a union makes it reusable and self-documenting.

type LoadState = "idle" | "loading" | "success" | "error";

function render(state: LoadState) { /* ... */ }

Aliasing tuples

type Point = [x: number, y: number];
type RGB = [number, number, number];

Aliases can reference each other

type ID = string | number;
type Entity = { id: ID; createdAt: number };
type User = Entity & { name: string };
type Post = Entity & { title: string; authorId: ID };

Generic type aliases

Aliases accept type parameters, just like functions accept value parameters.

type Result<T> = { ok: true; value: T } | { ok: false; error: string };

const r: Result<number> = { ok: true, value: 42 };
const e: Result<string> = { ok: false, error: "not found" };

Type alias vs interface (quick recap)

• interface only describes object shapes.
• type describes anything — objects, unions, primitives, tuples, function signatures.
• Aliases can’t be redeclared/merged; interfaces can.

See the “Type vs Interface” note for the full comparison.

Naming conventions

A few common patterns teams use:

• PascalCase for type names (User, OrderStatus).
• No I prefix for interfaces (that’s a C# convention, not TS).
• Props suffix for React component props (ButtonProps).
• T prefix or just one letter for generics (T, K, V — or TItem if multiple).

Interview soundbite

“A type alias is a name for a type expression. It’s the simplest tool for reuse — define a shape once, use it everywhere. Unlike interfaces, aliases can name any type: unions, tuples, primitives, function signatures. They’re inert at runtime — purely a compile-time label.”

Narrowing is how TypeScript moves from a broad type (like string | number) to a specific one inside a branch of code. It’s TS’s secret sauce — the compiler reads our control flow and adjusts the type at each step.

In simple language, the compiler runs through our if/else and updates what it thinks the type is, the same way our brain does when reading the code.

typeof — for primitives

The classic. TS recognizes typeof x === "string" | "number" | "boolean" | "undefined" | "object" | "function" | "bigint" | "symbol".

function double(x: string | number): string | number {
  if (typeof x === "number") {
    return x * 2;          // x is number here
  }
  return x.repeat(2);      // x is string here
}

instanceof — for class instances

class Dog { bark() { console.log("woof"); } }
class Cat { meow() { console.log("meow"); } }

function speak(pet: Dog | Cat) {
  if (pet instanceof Dog) {
    pet.bark();   // narrowed to Dog
  } else {
    pet.meow();   // narrowed to Cat
  }
}

in operator — check property existence

Great for narrowing between object types without a discriminator.

type Bird = { fly: () => void };
type Fish = { swim: () => void };

function move(animal: Bird | Fish) {
  if ("fly" in animal) {
    animal.fly();   // Bird
  } else {
    animal.swim();  // Fish
  }
}

Equality narrowing

Comparing to a literal narrows.

function f(x: string | null) {
  if (x === null) return;
  x.toUpperCase(); // x is string here
}

This is also how discriminated unions narrow on a kind/type field.

Truthiness narrowing

if (value) narrows away null, undefined, "", 0, false.

function f(x: string | null | undefined) {
  if (x) {
    x.toUpperCase(); // narrowed to string
  }
}

Be careful — empty string and 0 are falsy. If we mean “not null/undefined”, use x != null (loose equality on purpose — catches both).

User-defined type guards (type predicates)

When the built-in narrowing isn’t enough, we can write our own. A type predicate is a function that returns arg is SomeType.

type Cat = { meow: () => void };
type Dog = { bark: () => void };

function isCat(animal: Cat | Dog): animal is Cat {
  return "meow" in animal;
}

function pet(animal: Cat | Dog) {
  if (isCat(animal)) {
    animal.meow(); // narrowed to Cat
  } else {
    animal.bark(); // narrowed to Dog
  }
}

The signature animal is Cat is a promise to the compiler: “if I return true, treat the argument as Cat from here on”. TS trusts us — make sure the runtime check actually matches.

Assertion functions

Cousin of type predicates. Throws if the check fails, narrows on the rest of the function after the call.

function assertIsString(val: unknown): asserts val is string {
  if (typeof val !== "string") throw new Error("Not a string");
}

function f(input: unknown) {
  assertIsString(input);
  input.toUpperCase(); // narrowed to string here on
}

Discriminated unions

The cleanest narrowing pattern — a shared literal field that uniquely identifies each variant. Big enough topic to have its own note.

type Shape =
  | { kind: "circle"; radius: number }
  | { kind: "square"; size: number };

function area(s: Shape): number {
  if (s.kind === "circle") return Math.PI * s.radius ** 2;
  return s.size ** 2;
}

never for exhaustiveness

A handy pattern — in the default branch of a switch, assign to never. If a new variant is added later, TS errors here.

function area(s: Shape): number {
  switch (s.kind) {
    case "circle": return Math.PI * s.radius ** 2;
    case "square": return s.size ** 2;
    default:
      const _exhaustive: never = s; // ❌ if Shape grows
      return _exhaustive;
  }
}

Interview soundbite

“Narrowing is TS reading our control flow and shrinking a broad type inside branches. Built-in tools: typeof, instanceof, in, equality, truthiness. For custom checks we write user-defined type guards returning arg is Type. The pattern matters because it’s how we work safely with union types.”

A discriminated union (also called a tagged union or algebraic data type) is a union of object types that all share one field — the discriminant — whose value is a literal type. That shared field tells TS exactly which variant we have.

In simple language: every shape carries a tag (kind, type, status, whatever) that uniquely identifies it. Check the tag, get the right type.

The shape of it

type Shape =
  | { kind: "circle"; radius: number }
  | { kind: "square"; size: number }
  | { kind: "rectangle"; width: number; height: number };

Every variant has a kind field with a unique string literal. Now TS can tell them apart just by checking kind.

Narrowing on the tag

function area(shape: Shape): number {
  switch (shape.kind) {
    case "circle":
      return Math.PI * shape.radius ** 2;  // shape is { kind: "circle"; radius: number }
    case "square":
      return shape.size ** 2;
    case "rectangle":
      return shape.width * shape.height;
  }
}

Inside each case, TS knows the exact variant. No casts, no as, no runtime type checks beyond the tag comparison.

Exhaustiveness check with never

The killer feature. Add a default case that assigns to never — if we ever extend the union and forget a case, TS errors right here.

function area(shape: Shape): number {
  switch (shape.kind) {
    case "circle": return Math.PI * shape.radius ** 2;
    case "square": return shape.size ** 2;
    case "rectangle": return shape.width * shape.height;
    default:
      const _exhaustive: never = shape; // ❌ if Shape gains a variant
      throw new Error(`Unhandled shape: ${_exhaustive}`);
  }
}

Add { kind: "triangle"; ... } to Shape later — every switch that doesn’t handle it lights up red. Compile-time refactor safety.

Real-world pattern: API results

This is the single most common use case. A request can succeed OR fail; the success and failure shapes are different.

type ApiResult<T> =
  | { status: "loading" }
  | { status: "success"; data: T }
  | { status: "error"; message: string };

function render(result: ApiResult<User>) {
  if (result.status === "loading") return "Loading...";
  if (result.status === "error")   return `Error: ${result.message}`;
  return `Hello ${result.data.name}`; // status is "success"
}

Notice how we never access data accidentally on a loading result — the type system blocks it.

Real-world pattern: Redux/state machine actions

type Action =
  | { type: "increment" }
  | { type: "decrement" }
  | { type: "set"; value: number };

function reducer(state: number, action: Action): number {
  switch (action.type) {
    case "increment": return state + 1;
    case "decrement": return state - 1;
    case "set":       return action.value; // safely access value
  }
}

Picking the discriminant

• Use a string literal field (kind, type, status). Not numeric — strings are clearer in logs.
• One field per union. Don’t try to discriminate on two fields at once.
• Same field name across all variants — that’s what makes the discrimination work.

Why not just instanceof?

Discriminated unions work with plain objects — no classes needed. They serialize cleanly to JSON, survive network boundaries, and are the standard pattern in functional languages (Rust enums, Haskell ADTs, OCaml variants).

Interview soundbite

“A discriminated union is a union of object types sharing one literal-typed field. The compiler narrows each branch based on that field — no casts, no runtime overhead. The never exhaustiveness pattern guarantees we handle every case, and any new variant added later breaks the build until we cover it.”

In simple language, a function type tells us what a function takes in and what it gives back. TypeScript lets us describe that shape so we can pass functions around safely.

The simplest way is to annotate the parameters and return type directly on the function declaration. The compiler then yells at us if we call it wrong.

function add(a: number, b: number): number {
  return a + b;
}

// inferred return type — TS figures it out
function double(x: number) {
  return x * 2; // inferred as number
}

Function type expressions

When we want to pass a function as a parameter (think: callbacks), we describe its shape with an arrow-style type. This is the most common pattern we’ll see.

type Greeter = (name: string) => string;

const hello: Greeter = (name) => `Hi, ${name}`;

function run(fn: (n: number) => boolean) {
  return fn(42);
}

The only difference between this and a regular type alias is the => — that’s how we say “this is a function that returns X”.

Call signatures (the object form)

Sometimes a function also has properties on it (like express’s app() which is callable but also has app.get). For those, we use call signatures inside an object type.

type CountedFn = {
  calls: number;
  (x: number): number; // call signature — no `=>`
};

function makeCounter(): CountedFn {
  const fn = ((x: number) => x * 2) as CountedFn;
  fn.calls = 0;
  return fn;
}

Construct signatures

For things meant to be called with new, we use new (...). Rare in app code, common in library typings.

type CtorOf<T> = new (...args: any[]) => T;

function create<T>(C: CtorOf<T>): T {
  return new C();
}

void vs undefined return

A void return means “the caller shouldn’t rely on the return value”. It does NOT mean the function must return nothing — it just means the value is ignored. This catches people off guard in interviews.

type Logger = (msg: string) => void;

const log: Logger = (msg) => msg.length; // OK — return is ignored

Why this matters

In real code, function signatures are the contract between modules. Get them right and refactors stay safe; get them wrong and runtime errors leak through. A common interview question: “What’s the difference between a function type expression and a call signature?” — expressions are for plain callable types, call signatures let us add properties.

In simple language, sometimes we don’t want every parameter to be mandatory. TypeScript gives us three tools for that: optional (?), default values, and rest (...).

Optional parameters

Add a ? after the name and the parameter becomes optional. Inside the function, its type becomes T | undefined, so we still need to handle the “not passed” case.

function greet(name: string, title?: string): string {
  // title is string | undefined here
  return title ? `${title} ${name}` : name;
}

greet("Manish");         // OK
greet("Manish", "Dr.");  // OK

Rule: optional parameters must come AFTER required ones. function bad(a?: string, b: number) is a compile error.

Default parameters

A default value makes the parameter optional AND gives it a fallback. Now we don’t need the | undefined check inside.

function greet(name: string, title: string = "Mr."): string {
  return `${title} ${name}`; // title is just string, never undefined
}

greet("Manish");           // "Mr. Manish"
greet("Manish", "Dr.");    // "Dr. Manish"
greet("Manish", undefined); // "Mr. Manish" — undefined triggers default

Defaults can be after required params too, and they can even reference earlier parameters. They don’t need to be at the end IF the call site passes undefined explicitly.

Rest parameters

When we don’t know how many arguments will come in, we collect them into an array with .... Think of it like the opposite of spread.

function sum(...nums: number[]): number {
  return nums.reduce((a, b) => a + b, 0);
}

sum(1, 2, 3);       // 6
sum();              // 0
sum(...[1, 2, 3]);  // 6 — spread back in

Rest must be the last parameter, and its type is always an array (or tuple).

Tuples in rest — the powerful trick

We can type rest params as a tuple to enforce specific positions. Super useful for things like event emitters.

type EventArgs = [event: string, payload: object];

function emit(...args: EventArgs) {
  const [event, payload] = args;
  console.log(event, payload);
}

emit("user.created", { id: 1 }); // OK

Common interview gotcha

What’s the difference between param?: string and param: string | undefined? The optional version lets us SKIP the argument at the call site; the union version forces us to pass undefined explicitly. Subtle but it shows up in API design.

function a(x?: string) {}
function b(x: string | undefined) {}

a();           // OK
b();           // Error — expected 1 argument
b(undefined);  // OK

In simple language, function overloading lets one function accept several different argument patterns, each with its own return type. TypeScript only does this at the type level — at runtime there’s still just one function.

The pattern: write 2+ “overload signatures” with no body, then ONE “implementation signature” with the body. Callers only see the overloads; the implementation is hidden.

// overload signatures (visible to callers)
function parse(input: string): object;
function parse(input: number): string;

// implementation signature (hidden, must be compatible with all overloads)
function parse(input: string | number): object | string {
  if (typeof input === "string") return JSON.parse(input);
  return input.toString();
}

const a = parse('{"x":1}'); // a: object
const b = parse(42);        // b: string

Why not just use unions?

Good question — and often a union is enough. The difference shows up when the return type DEPENDS on the input type.

// union version — return type is always the same
function bad(x: string | number): string | number {
  return x; // caller always gets string | number
}

// overload version — return narrows based on input
function good(x: string): string;
function good(x: number): number;
function good(x: string | number) { return x; }

const s = good("hi"); // s: string  ← narrowed!
const n = good(42);   // n: number

Rules to remember

1. The implementation signature is NOT callable from outside. Only the overloads are.
2. The implementation signature must be a superset of all overloads (its params/return must satisfy every overload).
3. Order matters — TypeScript picks the FIRST matching overload, so put the most specific one first.

function fmt(x: boolean): "yes" | "no";
function fmt(x: number): string;
function fmt(x: boolean | number): string {
  return typeof x === "boolean" ? (x ? "yes" : "no") : x.toFixed(2);
}

When to prefer overloading

• The return type changes based on input shape.
• Different parameter counts (e.g., slice(start) vs slice(start, end)).
• Mutually exclusive options (e.g., either pass id OR name, never both).

When to AVOID overloading

If a union or generic does the job, use that. Overloads are duplicate-y and easy to get out of sync. Modern advice: try function f<T extends ...> or conditional types first.

// often cleaner than overloads:
function pick<T extends "yes" | "no" | number>(x: T): T {
  return x;
}

Common interview prompt

“Write a function combine that returns string when both args are strings and number when both are numbers.” That’s a textbook overload — or a generic with conditional types, depending on how fancy we want to be.

In simple language, an interface describes the shape of an object — what properties it has and what types they are. It’s a contract: “anything that wants to be a User must have these fields”.

interface User {
  id: number;
  name: string;
  email: string;
}

const u: User = { id: 1, name: "Manish", email: "m@x.com" };

Optional and readonly

? marks a property as optional. readonly makes it immutable after creation — assignment after init is a compile error.

interface Post {
  readonly id: number;   // can't reassign after creation
  title: string;
  draft?: boolean;       // may or may not exist
}

const p: Post = { id: 1, title: "Hi" };
p.title = "Hey";  // OK
p.id = 2;         // Error — readonly

readonly is shallow — nested objects are still mutable.

Extending interfaces

One interface can extend another (or multiple). Think of it like the only difference is we’re stacking shapes.

interface Animal {
  name: string;
}

interface Dog extends Animal {
  breed: string;
}

interface ServiceDog extends Dog, Trainable {
  serviceType: string;
}

interface Trainable {
  trainerId: number;
}

Index signatures

When we don’t know all the keys ahead of time (think: a dictionary), we use an index signature. The key can be string, number, or symbol.

interface Translations {
  [locale: string]: string;
}

const t: Translations = {
  en: "Hello",
  hi: "Namaste",
};

t.es = "Hola"; // OK — any string key works

We can also mix named props with an index signature, but the named props must be assignable to the index value type.

interface Config {
  version: string;        // known
  [key: string]: string;  // anything else is also string
}

Interface vs type alias

Both can describe object shapes. Key differences:

• Interfaces can be re-opened (declaration merging) — handy for extending library types.
• Type aliases support unions, intersections, mapped types, conditional types.

interface Box { width: number; }
interface Box { height: number; } // merged!
// Box now requires { width, height }

type Status = "ok" | "fail"; // union — only type can do this

Rule of thumb: use interface for object shapes meant to be extended/implemented, type for unions, primitives, and computed types.

Implementing interfaces

Classes use implements to promise they match the shape. We’ll see this in the abstract classes note.

interface Printable {
  print(): void;
}

class Doc implements Printable {
  print() { console.log("printing..."); }
}

Interview gotcha

Excess property checks: object literals get extra-strict checks, but variables don’t. { id: 1, name: "x", extra: true } as User triggers an error, but assigning a variable with that shape doesn’t. This trips people up.

In simple language, access modifiers say “who’s allowed to touch this member”. TypeScript has four: public, private, protected, and readonly. They’re enforced at compile time only — at runtime, JavaScript doesn’t care.

class Account {
  public id: number;          // anyone can read/write
  private balance: number;    // only this class
  protected ownerId: number;  // this class + subclasses
  readonly createdAt: Date;   // anyone can read, no one can write after init

  constructor(id: number, ownerId: number) {
    this.id = id;
    this.balance = 0;
    this.ownerId = ownerId;
    this.createdAt = new Date();
  }
}

Visibility table

public — the default

If we don’t write a modifier, it’s public. Anyone can read and write.

private — class only

Only the class itself can access. Subclasses can’t either. Useful for internal state we don’t want anyone touching.

class Counter {
  private count = 0;
  inc() { this.count++; }
  get value() { return this.count; }
}

const c = new Counter();
c.count; // Error — private

protected — class + subclasses

Same as private, but subclasses can also see it. Common for shared helpers in inheritance hierarchies.

class Animal {
  protected speakVerb = "makes a sound";
  describe() { return `Animal ${this.speakVerb}`; }
}

class Dog extends Animal {
  bark() { return `Dog ${this.speakVerb}`; } // OK — protected reaches subclasses
}

readonly

Orthogonal to the others — can combine with public/private/protected. Means “no reassignment after constructor”.

class Config {
  readonly version = "1.0";
  private readonly secret: string;
  constructor(s: string) { this.secret = s; }
}

TS private vs JS #private

TypeScript’s private is compile-time only — at runtime, the property is just a regular field. JavaScript’s #private (with the hash) is runtime-enforced and totally invisible from outside.

class A {
  private x = 1;     // accessible via (a as any).x at runtime
  #y = 2;            // truly private, even at runtime
}

In interviews, this distinction matters — #y is preferred for real encapsulation in modern code.

Common gotcha

Two private fields with the same name across unrelated classes don’t clash, but TypeScript’s structural typing makes private members nominal — two classes with identical shapes but private fields are NOT assignable to each other. That’s intentional.

In simple language, an abstract class is a half-finished class. It can have real methods AND placeholder methods that subclasses must implement. We can’t new it directly — only its subclasses.

abstract class Shape {
  abstract area(): number;       // must be implemented by subclass

  describe(): string {           // real method — subclasses inherit
    return `area is ${this.area()}`;
  }
}

class Circle extends Shape {
  constructor(private r: number) { super(); }
  area() { return Math.PI * this.r * this.r; }
}

const c = new Circle(5);
new Shape(); // Error — cannot create instance of abstract class

Abstract vs interface — when to use which

The only difference, basically:

• Interface: pure contract, no implementation, zero runtime presence.
• Abstract class: contract + shared implementation + runtime presence (you can have a constructor, fields, methods).

If we only need to describe a shape, interface. If we need shared code AND a contract, abstract class.

// shape contract only
interface Greeter {
  greet(): string;
}

// contract + shared logic
abstract class BaseGreeter {
  abstract name: string;
  greet() { return `Hi, ${this.name}`; }
}

implements — promising to match an interface

A class can promise it satisfies one or more interfaces. The compiler then verifies the shape matches.

interface Loggable {
  log(): void;
}

interface Serializable {
  toJSON(): string;
}

class User implements Loggable, Serializable {
  constructor(public name: string) {}
  log() { console.log(this.name); }
  toJSON() { return JSON.stringify({ name: this.name }); }
}

Important: implements is just a check. It does NOT change the class — it only verifies. So adding implements Loggable doesn’t give us a log method; we still have to write it.

extends vs implements

• extends: inherit from ONE class (gets fields, methods, prototype chain).
• implements: satisfy any number of interfaces (gets nothing, just checked).

A class can extends one class and implements multiple interfaces at the same time. Think of it like the only difference is what we get back — inheritance gives code, implementation gives a check.

class Admin extends User implements Loggable, Serializable {
  // ...
}

Abstract + protected combo

A common pattern: keep abstract methods protected so only subclasses (and the abstract class itself) can call them, while exposing a public template method.

abstract class Pipeline {
  run() {
    this.before();
    this.step();   // subclass fills this in
    this.after();
  }
  protected before() {}
  protected after() {}
  protected abstract step(): void;
}

class Etl extends Pipeline {
  protected step() { console.log("extracting..."); }
}

This is the Template Method pattern — common interview question.

Why abstract classes still matter

Even with interfaces being so powerful, abstract classes are great when:

• We need shared state (fields, not just methods).
• We have a common algorithm with customizable steps.
• We want to enforce constructor logic for all subclasses.

If none of those apply, interface is lighter and works just as well.

Two unrelated but very useful class features bundled into one note: static members and parameter properties.

Static members

In simple language, static means “this belongs to the class, not to instances”. Think of it like the only difference is whether we call it on the class itself or on an object made from the class.

class MathHelper {
  static PI = 3.14159;
  static square(n: number) { return n * n; }
}

MathHelper.PI;           // 3.14159
MathHelper.square(4);    // 16

const m = new MathHelper();
m.PI; // Error — PI is on the class, not the instance

Static fields are great for:

• Constants (HttpStatus.OK = 200).
• Counters shared across instances.
• Factory methods (User.fromJSON(...)).
• Singleton patterns.

class IdGenerator {
  private static counter = 0;
  static next() { return ++IdGenerator.counter; }
}

IdGenerator.next(); // 1
IdGenerator.next(); // 2

Static members can be public, private, protected, and readonly — same modifiers as instance members.

Static blocks

Modern TS supports static initialization blocks for setup that needs more than a single expression.

class Config {
  static envs: string[];
  static {
    Config.envs = process.env.NODE_ENV?.split(",") ?? [];
  }
}

Parameter properties — the constructor shortcut

This one saves SO much boilerplate. Adding an access modifier (or readonly) to a constructor parameter automatically declares AND assigns it as a field.

// the long way
class User {
  name: string;
  age: number;
  constructor(name: string, age: number) {
    this.name = name;
    this.age = age;
  }
}

// the short way — parameter properties
class User2 {
  constructor(public name: string, public age: number) {}
}

Both produce the exact same class. The second version is way nicer for DTO-style classes.

Any modifier works — public, private, protected, readonly, or combinations:

class Account {
  constructor(
    public readonly id: number,
    private balance: number,
    protected ownerId: number,
  ) {}
}

Mixing parameter properties with regular params

We can mix freely — params with modifiers become fields, params without modifiers stay as plain locals.

class Order {
  constructor(
    public id: number,           // becomes field
    items: string[],             // just a local
  ) {
    console.log(items.length);   // use locally, then it's gone
  }
}

Interview gotchas

1. Static this: inside a static method, this refers to the CLASS, not an instance. Useful for static factories that need to be inheritable.

class Base {
  static create<T extends typeof Base>(this: T): InstanceType<T> {
    return new this() as InstanceType<T>;
  }
}

class Child extends Base {}
const c = Child.create(); // c: Child

2. Parameter properties don’t work with destructuring — constructor(public { a, b }: { a: number, b: number }) is not allowed. We have to destructure inside the body.

3. Static and instance with the same name are allowed — they live in different scopes. Confusing but legal.

In simple language, a generic is a placeholder for a type. We write the function once, and the caller (or the compiler) fills in the actual type. Think of it like a function parameter, but for types instead of values.

The classic example: an identity function that returns whatever it’s given.

// without generics — we lose type info
function identityBad(x: any): any {
  return x;
}
const a = identityBad("hi"); // a: any  — we lost "string"!

// with generics — type flows through
function identity<T>(x: T): T {
  return x;
}
const b = identity("hi"); // b: string — TS inferred T = string
const c = identity(42);   // c: number

The <T> is the type parameter. By convention we start with T, then U, V, etc. — but feel free to use descriptive names like <Key, Value>.

Why generics matter

They let us write reusable code WITHOUT falling back to any. The compiler still knows the real types, so autocomplete, refactoring, and error checking all keep working.

function first<T>(arr: T[]): T | undefined {
  return arr[0];
}

const n = first([1, 2, 3]);     // n: number | undefined
const s = first(["a", "b"]);    // s: string | undefined

Multiple type parameters

We can have as many as we need. Common pattern: mapping one type to another.

function pair<A, B>(a: A, b: B): [A, B] {
  return [a, b];
}

const p = pair("manish", 28); // p: [string, number]

Type inference vs explicit type arguments

Usually TS figures out the type from the arguments. If it can’t (or guesses wrong), we pass it explicitly.

function wrap<T>(x: T): T[] { return [x]; }

wrap(5);            // T inferred as number
wrap<string>("hi"); // T explicit — useful when no arg helps inference

Generic function expressions

Same syntax, different position:

const map = <T, U>(arr: T[], fn: (x: T) => U): U[] =>
  arr.map(fn);

const lengths = map(["abc", "de"], (s) => s.length);
// lengths: number[]

Generic in callback positions

This is where generics really shine — typing higher-order functions.

function withRetry<T>(fn: () => T, tries: number): T {
  for (let i = 0; i < tries - 1; i++) {
    try { return fn(); } catch {}
  }
  return fn(); // last try — let it throw
}

const result = withRetry(() => fetch("/api"), 3); // result: Response

Common interview question

“Write a typed version of Array.prototype.map.” That’s basically the map example above — and it’s a one-liner that tests both generics AND callback typing.

Gotcha: generics in arrow functions inside .tsx

In .tsx files, const f = <T>(x: T) => x is parsed as JSX. Workarounds: const f = <T,>(x: T) => x (trailing comma) or const f = <T extends unknown>(x: T) => x. Not relevant for .ts files.

Generics are the foundation for everything in the next two notes (constraints, generic classes), so this one’s worth getting solid.

In simple language, a bare <T> accepts literally any type — which sometimes means we can’t do anything useful inside the function. Generic constraints (T extends Something) say “T can be anything, but at minimum it has these properties”.

// bare generic — we don't know T has .length
function logLength<T>(x: T) {
  console.log(x.length); // Error — Property 'length' does not exist on type 'T'
}

// constrained — T must have .length
function logLength2<T extends { length: number }>(x: T) {
  console.log(x.length); // OK
}

logLength2("hello");       // OK — strings have length
logLength2([1, 2, 3]);     // OK — arrays have length
logLength2({ length: 5 }); // OK — duck-typed
logLength2(42);            // Error — number has no length

How to think about constraints

Constraint referring to another type parameter

We can have one type parameter constrain another. Very common when we want a “key of an object” type-safe getter.

function getProp<T, K extends keyof T>(obj: T, key: K): T[K] {
  return obj[key];
}

const user = { name: "Manish", age: 28 };
const n = getProp(user, "name"); // n: string
const a = getProp(user, "age");  // a: number
getProp(user, "xyz");            // Error — "xyz" is not a key of user

This is one of the most-asked patterns in interviews — typed property access.

Constraints with default types

We can give a type parameter a default, used when the caller doesn’t specify one.

function createState<T = string>(initial: T): { value: T } {
  return { value: initial };
}

const a = createState("hi");        // T inferred as string
const b = createState<number>(0);   // T explicit
const c = createState();            // Error — initial required, but T defaults to string

Constraining to unions

We can require T to be one of a set of literal types.

type HttpMethod = "GET" | "POST" | "PUT" | "DELETE";

function request<M extends HttpMethod>(method: M, url: string) {
  return { method, url };
}

request("GET", "/users");  // OK
request("PATCH", "/x");    // Error — not in the union

extends in conditionals — quick mention

extends also appears in conditional types (T extends U ? X : Y). Same keyword, different role — there it’s a type-level “is T assignable to U” check, not a constraint. We’ll dig into that in the conditional types note.

Common interview question

“Implement a type-safe pick(obj, ...keys).” The answer uses K extends keyof T and a rest tuple:

function pick<T, K extends keyof T>(obj: T, ...keys: K[]): Pick<T, K> {
  const out = {} as Pick<T, K>;
  for (const k of keys) out[k] = obj[k];
  return out;
}

const u = { id: 1, name: "M", age: 28 };
const p = pick(u, "id", "name"); // p: { id: number; name: string }

Constraints are what take generics from “neat” to “actually useful in production”.

In simple language, generic functions let one function work with many types. Generic classes and interfaces do the same thing for whole objects — a Stack<number> and a Stack<string> share one definition but stay totally type-safe.

Generic interfaces

The type parameter goes right after the interface name. Inside, we can use it anywhere a type goes.

interface ApiResponse<T> {
  data: T;
  status: number;
  error?: string;
}

const r1: ApiResponse<string> = { data: "ok", status: 200 };
const r2: ApiResponse<{ id: number }> = { data: { id: 1 }, status: 200 };

The classic example: an interface for any container.

interface Box<T> {
  contents: T;
}

const numBox: Box<number> = { contents: 42 };
const strBox: Box<string> = { contents: "hi" };

Generic classes

Same pattern — type parameter after the class name, available throughout the class body.

class Stack<T> {
  private items: T[] = [];
  push(item: T) { this.items.push(item); }
  pop(): T | undefined { return this.items.pop(); }
  peek(): T | undefined { return this.items[this.items.length - 1]; }
  get size() { return this.items.length; }
}

const numStack = new Stack<number>();
numStack.push(1);
numStack.push("two"); // Error — must be number

const strStack = new Stack<string>();
strStack.push("hi"); // OK

Multiple type parameters

A Map<K, V> is the obvious one. Let’s write our own simplified version.

class Dictionary<K extends string | number, V> {
  private store: Record<string, V> = {};
  set(key: K, value: V) { this.store[String(key)] = value; }
  get(key: K): V | undefined { return this.store[String(key)]; }
}

const d = new Dictionary<string, number>();
d.set("age", 28);
const a = d.get("age"); // a: number | undefined

Implementing a generic interface

A class can implement a generic interface — and either lock the type in or stay generic itself.

interface Repository<T> {
  find(id: number): T | null;
  save(item: T): void;
}

// locked-in: user-specific repo
class UserRepo implements Repository<{ id: number; name: string }> {
  find(id: number) { return { id, name: "M" }; }
  save(item: { id: number; name: string }) { /* ... */ }
}

// stays generic: works for any T
class InMemoryRepo<T extends { id: number }> implements Repository<T> {
  private items: T[] = [];
  find(id: number) { return this.items.find(i => i.id === id) ?? null; }
  save(item: T) { this.items.push(item); }
}

Extending generic classes

A subclass can pass through the generic, lock it down, or add its own.

class Queue<T> {
  protected items: T[] = [];
  enqueue(x: T) { this.items.push(x); }
  dequeue(): T | undefined { return this.items.shift(); }
}

// lock T to string
class StringQueue extends Queue<string> {
  joinAll() { return this.items.join(","); }
}

// pass T through
class LoggedQueue<T> extends Queue<T> {
  enqueue(x: T) {
    console.log("adding", x);
    super.enqueue(x);
  }
}

Default type parameters

Just like with functions, classes and interfaces can have defaults.

interface Result<T = unknown, E = Error> {
  ok: boolean;
  value?: T;
  error?: E;
}

const r: Result = { ok: false, error: new Error("boom") };
// T defaults to unknown, E to Error

Common interview prompt

“Build a typed event emitter where .on('foo', handler) only accepts handlers matching the payload of foo.” That’s a generic interface keyed by event name plus a K extends keyof Events constraint — combines everything from the last three notes.

interface Events {
  login: { userId: number };
  logout: { reason: string };
}

class Emitter<E> {
  on<K extends keyof E>(event: K, handler: (payload: E[K]) => void) {
    /* register */
  }
}

const e = new Emitter<Events>();
e.on("login", (p) => p.userId);  // p: { userId: number }
e.on("logout", (p) => p.reason); // p: { reason: string }

Once we’re comfortable here, the rest of TypeScript’s advanced types — utility types, conditional types, mapped types — all build on this same foundation.

These three are the building blocks of every fancy TypeScript pattern we’ll write. In simple language: keyof gives us the keys of a type, typeof gives us the type of a value, and indexed access (T[K]) gives us the type of a property. Combine them and we can describe almost anything.

keyof — grab the keys as a union

keyof T returns a union of all the property names of T as string (or number) literals. Think of it like Object.keys() but at the type level.

type User = { id: number; name: string; email: string };

type UserKey = keyof User; // "id" | "name" | "email"

function getField(user: User, key: keyof User) {
  return user[key]; // safe — key is one of the real keys
}

The big win is that keyof follows the type around. If we add a field to User, UserKey updates automatically — no manual sync.

typeof — promote a value into a type

typeof (the TS one, not the JS one) takes a runtime value and asks “what is the type of this thing?”. Super useful when we have a config object or constant and want to derive a type from it instead of typing it twice.

const config = {
  apiUrl: "https://api.example.com",
  timeout: 5000,
  retries: 3,
};

type Config = typeof config;
// { apiUrl: string; timeout: number; retries: number }

The only difference from keyof is that typeof operates on values, while keyof operates on types. Chain them and we get the killer combo: keyof typeof config.

Indexed access — drill into a property’s type

T[K] reads the type of property K from type T. Just like bracket access in JS, except at the type level.

type User = { id: number; name: string; address: { city: string } };

type IdType = User["id"];           // number
type CityType = User["address"]["city"]; // string — we can nest
type IdOrName = User["id" | "name"];     // number | string — union of keys works too

The killer combo

The real power shows up when we chain all three. Here’s a type-safe pick function — the kind of thing interviewers love.

function pluck<T, K extends keyof T>(items: T[], key: K): T[K][] {
  return items.map((item) => item[key]);
}

const users = [{ id: 1, name: "Ada" }, { id: 2, name: "Linus" }];
const names = pluck(users, "name"); // string[]
const ids = pluck(users, "id");     // number[]
// pluck(users, "email");          // error — "email" not in keyof T

K extends keyof T constrains K to actual keys of T. The return type T[K][] uses indexed access to figure out what each value is. We get full type safety with zero duplication.

Arrays and number indexing

For arrays and tuples, indexed access with number gives the element type. Handy when we want to pull an element out of an array type.

const roles = ["admin", "editor", "viewer"] as const;
type Role = typeof roles[number]; // "admin" | "editor" | "viewer"

We just turned a runtime array into a union type. This pattern shows up everywhere — defining allowed values once and reusing them as both data and type.

In simple language, a mapped type is a for loop over the keys of a type. We take an existing type, iterate over its keys, and produce a new type where each property has been transformed somehow.

The syntax looks weird at first: { [K in keyof T]: ... }. Read it as “for each key K in the keys of T, give me back a property with this new shape”. It’s the type-level equivalent of Object.fromEntries(Object.keys(obj).map(...)).

The basic shape

type User = { id: number; name: string; email: string };

// Make every property optional — this is basically how Partial<T> is built
type PartialUser = { [K in keyof User]?: User[K] };
// { id?: number; name?: string; email?: string }

Notice three things: K in keyof User walks the keys, ? adds optionality, and User[K] is indexed access to grab the original property type. Swap those modifiers around and we get a whole family of transforms.

Mapping modifiers — ? and readonly

We can add or remove modifiers with + (default) or -. The - is the cool one because it strips modifiers that already exist.

type MakeOptional<T> = { [K in keyof T]?: T[K] };
type MakeRequired<T> = { [K in keyof T]-?: T[K] }; // strip optional
type Freeze<T> = { readonly [K in keyof T]: T[K] };
type Thaw<T> = { -readonly [K in keyof T]: T[K] };  // strip readonly

type LooseConfig = { host?: string; port?: number };
type StrictConfig = MakeRequired<LooseConfig>; // { host: string; port: number }

This is exactly how Partial, Required, Readonly are implemented in the standard lib — it’s just a thin wrapper around a mapped type.

Key remapping with as

TS 4.1+ lets us rename keys during mapping using as. Combine it with template literal types and we can build getter shapes, event handlers, anything name-based.

type User = { name: string; age: number };

type Getters<T> = {
  [K in keyof T as `get${Capitalize<string & K>}`]: () => T[K];
};

type UserGetters = Getters<User>;
// { getName: () => string; getAge: () => number }

The as clause runs per-key and decides the new key name. If we return never from the as, that key gets filtered out — which is how we exclude properties.

type RemoveKey<T, K extends keyof T> = {
  [P in keyof T as P extends K ? never : P]: T[P];
};

type WithoutEmail = RemoveKey<{ id: number; email: string }, "email">;
// { id: number }

Mapping a union of strings

K in doesn’t have to start from keyof — any union of keys works. Useful for building records out of thin air.

type Role = "admin" | "editor" | "viewer";

type RolePermissions = { [R in Role]: string[] };
// { admin: string[]; editor: string[]; viewer: string[] }

const perms: RolePermissions = {
  admin: ["read", "write", "delete"],
  editor: ["read", "write"],
  viewer: ["read"],
};