Forem: Animesh Pandey

[Boost]

Animesh Pandey — Wed, 31 Dec 2025 07:25:22 +0000

Matheus de Camargo Marques

Dec 30 '25

Are Feature Flags Bullsh*t? Why Your "IF" is Killing Performance (and the Planet)

#elixir #erlang #pon #actor

Comments

4 min read

TypeScript Expert Revision Handbook

Animesh Pandey — Sun, 31 Aug 2025 19:19:44 +0000

📑 Table of Contents

Fundamentals
Advanced Types
Generics in Depth
Type Inference & Compatibility
Type Safety in JavaScript Interop
Type Guards & Narrowing
Advanced Patterns
TypeScript in React
Performance & Scaling
Ecosystem & Future

🟦 Fundamentals (Expert Level)

1. 🧩 Type System vs Runtime Behavior

Definition:
TypeScript is a compile-time type system — all types are erased at runtime.

✅ Key Points

Types are structural, not nominal (duck typing).
Type checking = compile-time only.
At runtime, it’s just JavaScript.

⚠️ Gotchas

Type safety doesn’t prevent runtime errors:

function greet(name: string) {
  return "Hello " + name.toUpperCase();
}
greet((123 as unknown) as string); // compiles, but runtime crash

No runtime enforcement — you need runtime validators (zod, io-ts, yup).

🎯 Interview One-Liner

“TypeScript’s types disappear at runtime. They make dev-time guarantees, but runtime safety requires explicit validation.”

2. 🔢 Core Primitive Types

✅ Basic Types

string, number, boolean
null, undefined
symbol, bigint

✅ Special Types

any → Opt-out of type system (unsafe).
unknown → Safer alternative; must narrow before use.
never → Function that never returns (errors, infinite loops).
void → Function returns nothing.

⚠️ Gotchas

let x: any = 42;
x.toUpperCase(); // compiles, runtime crash

let y: unknown = 42;
y.toUpperCase(); // ❌ compile error

🎯 Interview One-Liner

“any disables safety. Prefer unknown when you don’t know the type, since it forces narrowing before use.”

3. 🏷️ Type Assertions vs Casting

Definition:
Tell the compiler “trust me, this is of type X.”

✅ Syntax

const el = document.getElementById("foo") as HTMLDivElement;

✅ Non-null Assertion

const el = document.getElementById("foo")!; // never null

⚠️ Gotchas

Overusing assertions bypasses safety.
Wrong assertions → runtime crashes.
Non-null ! can hide real null bugs.

🎯 Interview One-Liner

“Assertions tell TS to trust you. They don’t change runtime — overuse can hide real errors.”

4. 🔍 Type Narrowing (Control Flow Analysis)

Definition:
TS refines types based on runtime checks.

✅ Techniques

typeof
instanceof
Equality checks
Discriminated unions (tag property)

Example

function printLen(x: string | string[]) {
  if (typeof x === "string") console.log(x.length);
  else console.log(x.length); // string[] length
}

⚠️ Gotchas

Narrowing only works if TS can see the check.
External function calls won’t narrow unless you define type predicates.

function isString(x: unknown): x is string {
  return typeof x === "string";
}

🎯 Interview One-Liner

“TypeScript narrows unions using control flow. You can extend it with custom type predicates.”

5. 🚦 Strict Null Checking

Definition:
With strictNullChecks, null and undefined are not assignable to other types unless explicitly included.

✅ Example

let x: string = null; // ❌ error under strictNullChecks
let y: string | null = null; // ✅

✅ Optional Chaining + Nullish Coalescing

const name = user?.profile?.name ?? "Guest";

⚠️ Gotchas

Many JS libs don’t account for undefined.
Without strictNullChecks, you get unsound behavior (nullable everywhere).

🎯 Interview One-Liner

“Strict null checks make nullability explicit, avoiding the billion-dollar mistake. Combine with optional chaining and nullish coalescing.”

6. 🔎 Structural Typing (vs Nominal)

Definition:
TS uses structural typing — compatibility is based on shape, not declared type.

✅ Example

type Point = { x: number; y: number };
type Coord = { x: number; y: number };

let a: Point = { x: 1, y: 2 };
let b: Coord = a; // ✅ works (same shape)

⚠️ Gotchas

Extra properties are rejected in object literals:

let p: Point = { x: 1, y: 2, z: 3 }; // ❌ error

But extra props are allowed if passed as variable:

const tmp = { x: 1, y: 2, z: 3 };
let p: Point = tmp; // ✅ works

🎯 Interview One-Liner

“TypeScript is structurally typed — if it quacks like a duck, it’s assignable. But object literals have stricter excess property checks.”

7. 📝 Type Aliases vs Interfaces

Definition:
Two ways to define object types.

✅ Differences

Interface: extendable via declaration merging.
Type Alias: supports unions, intersections, primitives.

Example

interface A { x: number }
interface A { y: number } // merged
type B = { x: number } & { y: number } // no merging, must intersect

⚠️ Gotchas

Prefer interface for public APIs (extendable).
Prefer type for unions and complex compositions.

🎯 Interview One-Liner

“Interfaces are open (mergeable), types are closed but more flexible (unions, intersections). Use each where it fits.”

8. 📦 Enums vs Literal Types

✅ Enums

enum Direction { Up, Down }

✅ Literal Unions

type Direction = "up" | "down";

⚠️ Gotchas

String literal unions are usually better (type-safe, no runtime overhead).
Enums generate runtime objects → heavier.
const enum is inlined at compile time but can break tooling.

🎯 Interview One-Liner

“Prefer literal unions over enums — they’re lighter and more type-safe. Use enums only when runtime mapping is required.”

🟦 Advanced Types

1. ➕ Union & Intersection Types

✅ Union (`|`)

Represents either type.

type Input = string | number;
let val: Input = "hi";  // ✅
val = 42;               // ✅

✅ Intersection (`&`)

Combines multiple types.

type Person = { name: string };
type Worker = { company: string };
type Employee = Person & Worker; 
// { name: string; company: string }

⚠️ Gotchas

Union narrows to shared members:

function len(x: string | string[]) {
  return x.length; // works (length exists on both)
}

Intersection of incompatible types → never:

type Impossible = string & number; // never

🎯 One-Liner

“Unions = OR, intersections = AND. Incompatible intersections collapse to never.”

2. 🔢 Literal Types & Const Assertions

✅ Literal Types

let dir: "up" | "down";
dir = "up"; // ✅
dir = "left"; // ❌

✅ `as const`

Locks values into literal types.

const colors = ["red", "green"] as const;
type Color = typeof colors[number]; // "red" | "green"

🎯 One-Liner

“Literal types restrict values to exact strings/numbers. as const freezes arrays/objects for inference.”

3. 📝 Template Literal Types

✅ Key Points

Build strings at type level.

type Event = `on${Capitalize<"click" | "hover">}`;
// "onClick" | "onHover"

✅ Use Cases

Event handler names.
Typed CSS props.
API route patterns.

🎯 One-Liner

“Template literal types compose strings at type level — great for event names, routes, and API typings.”

4. 🧮 Conditional Types

Definition:
T extends U ? X : Y

✅ Example

type IsString<T> = T extends string ? true : false;
type A = IsString<"hi">;   // true
type B = IsString<number>; // false

✅ Distributive Behavior

type ToArray<T> = T extends any ? T[] : never;
type C = ToArray<string | number>; // string[] | number[]

⚠️ Gotchas

Distribution only happens on naked type parameters.
Use brackets to disable:

type NoDistrib<T> = [T] extends [any] ? T[] : never;

🎯 One-Liner

“Conditional types let you branch at type level. By default they distribute over unions.”

5. 🗂️ Mapped Types

✅ Basics

type OptionsFlags<T> = {
  [K in keyof T]: boolean;
};
type Features = { darkMode: () => void };
type Flags = OptionsFlags<Features>; 
// { darkMode: boolean }

✅ Modifiers

readonly
? optional
-readonly / -? to remove

type Mutable<T> = { -readonly [K in keyof T]: T[K] };

🎯 One-Liner

“Mapped types iterate over keys to transform shape — add/remove optionality, readonly, etc.”

6. 🛠️ Utility Types

✅ Built-ins

Partial<T> → all optional
Required<T> → all required
Readonly<T> → all readonly
Pick<T, K> → subset
Omit<T, K> → all except
Record<K, V> → dict type
ReturnType<T> → infer fn return
Parameters<T> → tuple of args
InstanceType<T> → type of new T()

Example

type Todo = { id: number; title: string; done?: boolean };
type TodoDraft = Partial<Todo>; // all optional

🎯 One-Liner

“Utility types like Partial, Pick, Omit, Record abstract common transformations of object types.”

7. 🧩 Key Remapping in Mapped Types (TS 4.1+)

type Prefix<T> = {
  [K in keyof T as `on${Capitalize<string & K>}`]: T[K]
};
type Events = Prefix<{ click: () => void }>;
// { onClick: () => void }

🎯 One-Liner

“Mapped types can rename keys dynamically using as clauses and template literals.”

8. 🌀 Recursive & Deep Types

✅ Recursive Types

type JSONValue = string | number | boolean | JSONValue[] | { [k: string]: JSONValue };

✅ Deep Utility

type DeepPartial<T> = { [K in keyof T]?: DeepPartial<T[K]> };

⚠️ Gotchas

Deep recursion can slow compiler dramatically.
Use cautiously in very large codebases.

🎯 One-Liner

“Recursive types enable JSON-like structures and deep utilities, but may hit compiler perf limits.”

🟦 Generics in Depth

1. 🧩 Generic Functions

Definition:
Functions parameterized with type variables.

✅ Example

function identity<T>(arg: T): T {
  return arg;
}
const a = identity<string>("hello");
const b = identity(42); // inferred as number

🎯 One-Liner

“Generics make functions reusable across types, with inference for convenience.”

2. 🔒 Constraints (`extends`)

Restrict generics to a subset of types.

✅ Example

function getLength<T extends { length: number }>(x: T) {
  return x.length;
}
getLength("hi");       // ✅
getLength([1,2,3]);    // ✅
getLength(42);         // ❌

🎯 One-Liner

“Constraints limit generics with extends, allowing access to known members.”

3. 🏷️ Generic Interfaces & Classes

✅ Interfaces

interface Box<T> { value: T }
const stringBox: Box<string> = { value: "hi" };

✅ Classes

class Container<T> {
  constructor(public value: T) {}
}
const c = new Container<number>(123);

🎯 One-Liner

“Generics extend beyond functions — interfaces and classes can also be parameterized.”

4. ⚖️ Default Generic Parameters

Provide defaults for flexibility.

✅ Example

interface ApiResponse<T = any> {
  data: T;
  error?: string;
}
const res: ApiResponse = { data: "hi" }; // T defaults to any

🎯 One-Liner

“Defaults reduce boilerplate when generic type can be inferred or safely assumed.”

5. 🔄 Keyof & Indexed Access with Generics

✅ Keyof

type Keys<T> = keyof T;
type User = { id: number; name: string };
type UKeys = Keys<User>; // "id" | "name"

✅ Indexed Access

type Value<T, K extends keyof T> = T[K];
type NameType = Value<User, "name">; // string

🎯 One-Liner

“Keyof + indexed access lets you make type-safe utilities (like Pick/Omit).”

6. 🎭 Conditional Generics

Generics inside conditional types = super powerful.

✅ Example

type Flatten<T> = T extends any[] ? T[number] : T;
type A = Flatten<string[]>; // string
type B = Flatten<number>;   // number

🎯 One-Liner

“Conditional generics let you branch inside generics — e.g., flatten arrays, unwrap promises.”

7. ⚖️ Variance (Covariance vs Contravariance)

Definition:
How subtyping interacts with generics.

✅ Covariance

Safe to use subtype in place of supertype.

let str: string = "hi";
let val: string | number = str; // ✅

✅ Contravariance

Function parameters are contravariant:

type Fn<T> = (x: T) => void;
let fn: Fn<string | number> = (x: string) => {}; // ✅

⚠️ Gotchas

TypeScript uses bivariant function parameters by default for compatibility (unsafe but practical).
--strictFunctionTypes enforces contravariance.

🎯 One-Liner

“Function parameters are contravariant, return types are covariant. TS is bivariant by default unless strictFunctionTypes is on.”

8. 🌀 Higher-Kinded Types (HKTs, Workarounds)

TypeScript doesn’t support true HKTs (types parameterized over type constructors), but you can simulate.

✅ Example

interface Functor<F> {
  map<A, B>(fa: F & { value: A }, fn: (a: A) => B): F & { value: B }
}

Or libraries like fp-ts emulate HKT with encoding tricks.

🎯 One-Liner

“TypeScript lacks HKTs, but libraries like fp-ts emulate them with encoding patterns.”

9. 🔗 Generics in React

✅ Typing `useState`

const [val, setVal] = useState<string | null>(null);

✅ Typing `useReducer`

type Action = { type: "inc" } | { type: "dec" };
function reducer(s: number, a: Action): number {
  return a.type === "inc" ? s+1 : s-1;
}
const [count, dispatch] = useReducer(reducer, 0);

✅ Typing Props

interface ButtonProps<T extends "button" | "a"> {
  as: T;
  props: T extends "a" ? { href: string } : { onClick: () => void };
}

🎯 One-Liner

“Generics in React type hooks, props, reducers, and flexible components (e.g., polymorphic components).”

🟦 Type Inference & Compatibility

1. 🔍 Type Inference Basics

Definition:
TypeScript infers types when not explicitly annotated.

✅ Examples

let x = 42;      // inferred as number
let y = [1, 2];  // inferred as number[]

✅ Contextual Typing

Function parameters infer type from usage:

window.onmousedown = (e) => { 
  console.log(e.button); // e inferred as MouseEvent
};

🎯 One-Liner

“Type inference works both from initializer values and from context (like callbacks).”

2. ⚖️ Excess Property Checks

Definition:
TypeScript enforces stricter checks for object literals.

✅ Example

type User = { name: string };
const u1: User = { name: "Alice", age: 30 }; // ❌ excess property
const tmp = { name: "Alice", age: 30 };
const u2: User = tmp; // ✅ allowed (assignment, not literal)

⚠️ Gotchas

Literal checks prevent typos in inline objects.
Assigning via variable bypasses check.

🎯 One-Liner

“Object literals get extra checks for unknown properties. Assign via variable to bypass.”

3. 🔄 Type Widening & Narrowing

✅ Widening

Without as const, literal types widen:

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

✅ Narrowing

Control-flow analysis narrows union types:

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

⚠️ Gotchas

let x = null → type is any unless strictNullChecks.
Arrays widen unless frozen with as const.

🎯 One-Liner

“TS widens literals by default. Use as const to keep narrow literal types.”

4. 🏷️ Assignability & Compatibility

Definition:
TypeScript is structurally typed → assignability depends on shape.

✅ Example

type Point = { x: number; y: number };
type Coord = { x: number; y: number; z?: number };

let p: Point = { x: 1, y: 2 };
let c: Coord = p;  // ✅ works
p = c;             // ✅ works (z optional)

⚠️ Gotchas

Function parameters are bivariant by default (unsafe).
Use strictFunctionTypes for true contravariance.

🎯 One-Liner

“TS uses structural typing: if shapes match, types are compatible. Functions default to bivariant params unless strict.”

5. 🧩 `any` vs `unknown` vs `never`

✅ any

Opt-out of type checking.
Can be assigned to/from anything.

let a: any = 42;
a.foo.bar(); // compiles, runtime error

✅ unknown

Top type (safe any).
Must be narrowed before use.

let b: unknown = 42;
b.toUpperCase(); // ❌ error
if (typeof b === "string") b.toUpperCase(); // ✅

✅ never

Bottom type (no value possible).
Used in exhaustiveness checks.

type Shape = { kind: "circle" } | { kind: "square" };
function area(s: Shape): number {
  switch (s.kind) {
    case "circle": return 1;
    case "square": return 2;
    default: const _exhaustive: never = s; // ✅ ensures all cases handled
  }
}

🎯 One-Liner

“any disables safety, unknown forces narrowing, never represents impossible cases.”

6. 🧠 Inference in Functions

✅ Return Inference

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

✅ Generic Inference

function first<T>(arr: T[]): T {
  return arr[0];
}
const v = first(["a", "b"]); // v: string

⚠️ Gotchas

Sometimes inference is too wide:

function f() { return Math.random() ? "a" : "b"; }
// inferred as string, not "a"|"b"

→ Fix with as const or explicit typing.

🎯 One-Liner

“Function return types are inferred, but unions may widen. Use as const or annotations for precision.”

7. 🛠️ Type Compatibility in Enums

✅ Numeric Enums

Compatible with numbers.

enum Dir { Up, Down }
let d: Dir = 0; // ✅

✅ String Enums

Not compatible with strings unless explicitly.

enum Color { Red = "red" }
let c: Color = "red"; // ❌

🎯 One-Liner

“Numeric enums are assignable to numbers, but string enums require exact matches.”

8. ⚡ Type Compatibility in Tuples vs Arrays

✅ Tuples

type Pair = [string, number];
let p: Pair = ["hi", 42];

Tuples have fixed length, arrays are flexible.

⚠️ Gotchas

let t: [number, number] = [1, 2];
t.push(3); // ✅ allowed! TS doesn’t enforce length at runtime

🎯 One-Liner

“Tuples enforce order but not length at runtime — they’re arrays under the hood.”

🟦 Type Safety in JavaScript Interop

1. 📜 Ambient Declarations (`declare`)

Definition:
Tell TypeScript about variables/modules that exist at runtime (JS), but aren’t defined in TS code.

✅ Examples

declare const VERSION: string;
console.log(VERSION); // TS knows VERSION is string

declare module "legacy-lib" {
  export function legacyFn(): void;
}

⚠️ Gotchas

Declarations don’t generate runtime code — only inform compiler.
If declaration doesn’t match actual runtime → runtime errors.

🎯 One-Liner

“declare informs the type system about external JS values but doesn’t emit code. Accuracy is critical or you’ll get runtime errors.”

2. 📦 Type Declarations for JS Libraries

✅ Strategies

@types packages:

npm install --save-dev @types/lodash

Manual d.ts files for missing types:

// lodash.d.ts
declare module "lodash" {
  export function chunk<T>(arr: T[], size: number): T[][];
}

⚠️ Gotchas

If types are outdated/mismatched → TS lies about API.
Can “augment” instead of redefining (see below).

🎯 One-Liner

“Missing types for JS libs? Install @types or write .d.ts files — but keep them accurate with the runtime.”

3. 🧩 Module Augmentation & Declaration Merging

Definition:
Extend existing module or type definitions without rewriting.

✅ Example

// add a method to lodash
declare module "lodash" {
  export function customHello(): string;
}

✅ Declaration Merging

Interfaces with the same name merge:

interface User { id: number }
interface User { name: string }
const u: User = { id: 1, name: "Alice" }; // ✅

⚠️ Gotchas

Augmentation is global → can cause conflicts across packages.
Prefer module augmentation for libs, not any hacks.

🎯 One-Liner

“Declaration merging/augmentation extends types safely. Useful for adding custom fields or extending 3rd-party libraries.”

4. 🎯 `as const` for Safe Interop

Definition:
as const freezes literals into readonly narrow types.

✅ Example

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

✅ Use Case

Ensures config/constants match at runtime.
Great for enums/union types from JS arrays.

🎯 One-Liner

“as const locks JS literals into readonly narrow types — perfect for role lists, config, or enum-like structures.”

5. ⚙️ `tsconfig` Strictness Flags

✅ Important Flags

strict → enables all strict checks.
noImplicitAny → no silent any.
strictNullChecks → enforce explicit nullability.
noUncheckedIndexedAccess → array lookups can return undefined.
exactOptionalPropertyTypes → ? means strictly optional.

⚠️ Gotchas

Teams often disable strictness → leaks any.
Migrating large JS → TS requires incremental adoption.

🎯 One-Liner

“Always enable strict. Key flags like noImplicitAny and strictNullChecks catch hidden bugs in JS interop.”

6. 🛠️ Working with Untyped JS Objects

✅ Options

Use unknown + type guards:

function isUser(u: any): u is { id: number } {
  return typeof u.id === "number";
}

Or validate at runtime with Zod/io-ts:

import { z } from "zod";
const User = z.object({ id: z.number(), name: z.string() });
type User = z.infer<typeof User>;

🎯 One-Liner

“Untyped JS objects should be validated at runtime with schemas (Zod/io-ts), not just trusted via any.”

7. 🔗 Migrating JS → TS (Gradual Typing)

✅ Strategies

Rename .js → .ts or .tsx.
Use allowJs + checkJs in tsconfig to gradually type JS.
Add JSDoc annotations:

/**
 * @param {string} name
 * @returns {string}
 */
function greet(name) { return "Hello " + name; }

TS infers types from JSDoc until converted.

⚠️ Gotchas

JSDoc typing is weaker than TS proper.
Incremental migration often mixes any → must clean up later.

🎯 One-Liner

“Migrate JS → TS gradually: enable checkJs, add JSDoc types, then refactor into full TypeScript.”

8. 🛡️ Runtime vs Compile-Time Safety

Core Rule:
Types vanish at runtime → if interoping with JS, you need runtime checks.

✅ Example

function safeParse(json: string): unknown {
  try { return JSON.parse(json) } catch { return null }
}
const data = safeParse("not-json"); // type unknown
// must validate before using

🎯 One-Liner

“TypeScript only checks at compile time. For JS interop, add runtime validation to truly guarantee safety.”

🟦 Type Guards & Narrowing

1. 🔎 Built-in Type Guards: `typeof`

Definition:
typeof lets TypeScript narrow primitive types.

✅ Example

function log(val: string | number) {
  if (typeof val === "string") {
    console.log(val.toUpperCase()); // val: string
  } else {
    console.log(val.toFixed(2));    // val: number
  }
}

⚠️ Gotchas

Only works on primitives: "string" | "number" | "boolean" | "bigint" | "symbol" | "undefined" | "object" | "function".
Doesn’t differentiate null vs object (typeof null === "object").

🎯 One-Liner

“Use typeof for primitives — but note typeof null === 'object'.”

2. 🏗️ Built-in Type Guards: `instanceof`

Definition:
Narrow objects by checking prototype chain.

✅ Example

function handleError(e: Error | string) {
  if (e instanceof Error) {
    console.error(e.message); // Error
  } else {
    console.error(e); // string
  }
}

⚠️ Gotchas

Only works with classes/constructors (not plain objects).
Inheritance hierarchy is respected.

🎯 One-Liner

“Use instanceof for class-based narrowing — it checks prototype chain.”

3. 🧩 In-Operator Narrowing

Definition:
Check if a property exists in object → narrows union.

✅ Example

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

function speak(animal: Cat | Dog) {
  if ("meow" in animal) animal.meow();
  else animal.bark();
}

🎯 One-Liner

“The in operator narrows unions by checking for property existence.”

4. 🏷️ Discriminated (Tagged) Unions

Definition:
Unions with a common literal field (“tag”) for safe narrowing.

✅ Example

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

function area(s: Shape) {
  switch (s.kind) {
    case "circle": return Math.PI * s.radius ** 2;
    case "square": return s.side ** 2;
  }
}

🎯 One-Liner

“Discriminated unions use a common literal field to guarantee safe narrowing in switches.”

5. 🛠️ Custom Type Predicates

Definition:
User-defined functions that tell TS a condition implies a type.

✅ Example

function isString(x: unknown): x is string {
  return typeof x === "string";
}

function log(x: unknown) {
  if (isString(x)) console.log(x.toUpperCase());
}

🎯 One-Liner

“Custom type predicates (x is T) let you teach TS how to narrow beyond built-ins.”

6. 🚦 Exhaustiveness Checking with `never`

Definition:
Force handling all cases in a union.

✅ Example

type Shape =
  | { kind: "circle"; r: number }
  | { kind: "square"; s: number };

function perimeter(s: Shape) {
  switch (s.kind) {
    case "circle": return 2 * Math.PI * s.r;
    case "square": return 4 * s.s;
    default:
      const _exhaustive: never = s; // compile error if new case added
      return _exhaustive;
  }
}

🎯 One-Liner

“Exhaustiveness checks with never ensure all union cases are handled — future-proofing code.”

7. 🧠 Control Flow Analysis

Definition:
TS tracks variables through branches to narrow automatically.

✅ Example

function f(x: string | null) {
  if (!x) return; 
  // x is now string, since null was filtered out
  return x.toUpperCase();
}

⚠️ Gotchas

TS is flow-sensitive — order matters.
Reassignments can widen again.

🎯 One-Liner

“TS narrows types flow-sensitively — once a check passes, TS refines type until reassignment.”

8. 🧩 Assertion Functions (TS 3.7+)

Definition:
Custom functions that throw on invalid values while narrowing type.

✅ Example

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

function shout(x: any) {
  assertIsString(x);
  console.log(x.toUpperCase()); // x: string
}

🎯 One-Liner

“Assertion functions throw at runtime and tell TS the variable is narrowed if no error occurs.”

9. 📦 Combining Guards

✅ Example

function handle(input: string | number | null) {
  if (input == null) return;          // null/undefined filtered
  if (typeof input === "string") {    // narrowed to string
    return input.toUpperCase();
  }
  return input.toFixed(2);            // number
}

🎯 One-Liner

“Combine guards (== null, typeof, instanceof) for precise narrowing of complex unions.”

🟦 Advanced Patterns

1. 🏷️ Branded Types (Nominal Typing in TS)

Problem:
TS is structural — type UserId = string is indistinguishable from any string.

Solution:
Add a “brand” field to enforce nominal typing.

✅ Example

type UserId = string & { __brand: "UserId" };
function getUser(id: UserId) {}
getUser("123" as UserId);  // ✅
getUser("random");         // ❌ must be branded

🎯 One-Liner

“Branded types simulate nominal typing in TS, preventing accidental mixing of structurally identical types.”

2. 🌀 Opaque Types

Definition:
Similar to branded types, but completely hide the underlying type from consumers.

✅ Example

type Opaque<K, T> = T & { __TYPE__: K };
type UserId = Opaque<"UserId", string>;

function createUserId(s: string): UserId {
  return s as UserId;
}

🎯 One-Liner

“Opaque types hide implementation details and prevent misuse, forcing controlled constructors.”

3. 🛠️ Recursive Utility Types

✅ DeepPartial

type DeepPartial<T> = {
  [K in keyof T]?: DeepPartial<T[K]>;
};

✅ DeepReadonly

type DeepReadonly<T> = {
  readonly [K in keyof T]: DeepReadonly<T[K]>;
};

⚠️ Gotchas

Deep recursion can slow down compiler.
Use selectively in large projects.

🎯 One-Liner

“Recursive types enable deep utilities like DeepPartial, but heavy use impacts compiler performance.”

4. 🧩 Conditional & Mapped Utilities

✅ NonNullable

type NonNullable<T> = T extends null | undefined ? never : T;

✅ Diff

type Diff<T, U> = T extends U ? never : T;

✅ Overwrite

type Overwrite<T, U> = Omit<T, keyof U> & U;

🎯 One-Liner

“Mapped + conditional types let you build powerful utilities like Diff, Overwrite, NonNullable.”

5. 🔄 Variadic Tuple Types

Definition:
Model tuples of variable length with generics.

✅ Example

type Push<T extends any[], V> = [...T, V];
type T1 = Push<[1,2], 3>; // [1,2,3]

type Concat<T extends any[], U extends any[]> = [...T, ...U];
type T2 = Concat<[1,2], [3,4]>; // [1,2,3,4]

🎯 One-Liner

“Variadic tuple types let you append, prepend, or merge tuples while preserving type precision.”

6. 🏗️ Builder Pattern in TypeScript

✅ Example

class RequestBuilder {
  private url: string = "";
  private method: "GET" | "POST" = "GET";

  setUrl(url: string) { this.url = url; return this; }
  setMethod(m: "GET" | "POST") { this.method = m; return this; }
  build() { return { url: this.url, method: this.method }; }
}

const req = new RequestBuilder().setUrl("/api").setMethod("POST").build();

🎯 One-Liner

“Builder patterns ensure chained configuration APIs with type safety and autocomplete.”

7. 🛡️ Exact Types (Prevent Excess Keys)

Problem:
TS normally allows extra props via assignment.

Solution:
Create an Exact<T, U> utility.

✅ Example

type Exact<T, U extends T> = T & { [K in Exclude<keyof U, keyof T>]?: never };

type Person = { name: string };
const p: Exact<Person, { name: string; age: number }> = { name: "A", age: 20 }; 
// ❌ error: extra 'age'

🎯 One-Liner

“Exact types prevent excess keys, useful for APIs where only known fields are allowed.”

8. 📦 Extracting Types from Values

✅ typeof + keyof

const config = {
  roles: ["admin", "user", "guest"] as const,
};
type Role = typeof config["roles"][number]; 
// "admin" | "user" | "guest"

🎯 One-Liner

“Use typeof and as const to derive union types from runtime values like config arrays.”

9. 🧠 Phantom Types (Static Guarantees)

Definition:
Types that exist only at compile-time, to encode invariants.

✅ Example

type Celsius = number & { __unit: "Celsius" };
type Fahrenheit = number & { __unit: "Fahrenheit" };

function toF(c: Celsius): Fahrenheit { return (c * 9/5 + 32) as Fahrenheit; }

let t: Celsius = 100 as Celsius;
toF(t); // ✅
toF(100 as Fahrenheit); // ❌

🎯 One-Liner

“Phantom types enforce domain-specific rules (like units) without runtime cost.”

🟦 TypeScript in React

1. 🎯 Typing Component Props

✅ Functional Components

type ButtonProps = {
  label: string;
  onClick?: () => void;
};

const Button: React.FC<ButtonProps> = ({ label, onClick }) => (
  <button onClick={onClick}>{label}</button>
);

⚠️ Gotchas

React.FC implicitly adds children prop — often unwanted.
Better to type children explicitly.

type Props = { children?: React.ReactNode };

🎯 One-Liner

“Prefer explicit prop typing over React.FC to avoid hidden children.”

2. 🏷️ Children Typing

✅ Common Patterns

type Props = { children: React.ReactNode }; // anything renderable
type Props2 = { children: React.ReactElement }; // exactly one element
type Props3<T> = { children: (data: T) => React.ReactNode }; // render prop

🎯 One-Liner

“Use ReactNode for generic children, ReactElement for single elements, and functions for render props.”

3. 🧩 Typing Hooks (`useState`, `useReducer`)

✅ useState

const [count, setCount] = useState<number>(0); // explicit
const [name, setName] = useState("Alice"); // inferred as string

useState<T | null>(null) when initial value is null.

✅ useReducer

type Action = { type: "inc" } | { type: "dec" };
function reducer(state: number, action: Action): number {
  switch (action.type) {
    case "inc": return state + 1;
    case "dec": return state - 1;
  }
}
const [count, dispatch] = useReducer(reducer, 0);

🎯 One-Liner

“Type state & actions explicitly in hooks. Use union types for reducers.”

4. 🌐 Typing Context Providers

✅ Example

type User = { id: string; name: string };
type UserContextType = { user: User | null; setUser: (u: User) => void };

const UserContext = React.createContext<UserContextType | undefined>(undefined);

function useUser() {
  const ctx = React.useContext(UserContext);
  if (!ctx) throw new Error("useUser must be inside UserProvider");
  return ctx;
}

🎯 One-Liner

“Context values should include both data and setters, wrapped in a custom hook for safety.”

5. 🧵 Typing Refs & forwardRef

✅ DOM Refs

const inputRef = React.useRef<HTMLInputElement>(null);
inputRef.current?.focus();

✅ forwardRef

type InputProps = { label: string };
const Input = React.forwardRef<HTMLInputElement, InputProps>(
  ({ label }, ref) => <input ref={ref} placeholder={label} />
);

✅ useImperativeHandle

type Handle = { focus: () => void };
const CustomInput = React.forwardRef<Handle>((props, ref) => {
  const inputRef = React.useRef<HTMLInputElement>(null);
  React.useImperativeHandle(ref, () => ({
    focus: () => inputRef.current?.focus(),
  }));
  return <input ref={inputRef} />;
});

🎯 One-Liner

“Use forwardRef with generic ref types. Expose imperative APIs with useImperativeHandle.”

6. 🧮 Typing Higher-Order Components (HOCs)

✅ Example

function withLoading<T>(Component: React.ComponentType<T>) {
  return (props: T & { loading: boolean }) =>
    props.loading ? <div>Loading...</div> : <Component {...props} />;
}

⚠️ Gotchas

Must preserve props (T) and merge with new ones.
Watch out for lost generics when wrapping.

🎯 One-Liner

“HOCs should preserve original props via generics and merge additional ones.”

7. 🧑‍🔬 Typing Generic Components

✅ Example

type ListProps<T> = {
  items: T[];
  render: (item: T) => React.ReactNode;
};

function List<T>({ items, render }: ListProps<T>) {
  return <ul>{items.map(render)}</ul>;
}

<List items={[1, 2, 3]} render={(x) => <li>{x}</li>} />;

🎯 One-Liner

“Generic components let props depend on type parameters — perfect for reusable lists and tables.”

8. 🔄 Typing Event Handlers

✅ Example

function Form() {
  const handleChange = (e: React.ChangeEvent<HTMLInputElement>) => {
    console.log(e.target.value);
  };
  return <input onChange={handleChange} />;
}

✅ Common Event Types

React.MouseEvent<HTMLButtonElement>
React.ChangeEvent<HTMLInputElement>
React.FormEvent<HTMLFormElement>

🎯 One-Liner

“Use React’s synthetic event types (MouseEvent, ChangeEvent) for handlers, parameterized by element type.”

9. 🧩 Typing Polymorphic `as` Components

✅ Example

type PolymorphicProps<T extends React.ElementType> = {
  as?: T;
  children: React.ReactNode;
} & React.ComponentProps<T>;

function Box<T extends React.ElementType = "div">({ as, ...props }: PolymorphicProps<T>) {
  const Component = as || "div";
  return <Component {...props} />;
}

<Box as="a" href="https://ts">Link</Box>; // href type-safe

🎯 One-Liner

“Polymorphic components use as + generics + ComponentProps<T> to forward correct props.”

🟦 Performance & Scaling TypeScript

1. ⚡ Type-Checking Performance in Large Projects

✅ Common Bottlenecks

Deeply nested conditional types.
Overuse of recursive mapped types (e.g., DeepPartial, DeepReadonly).
Giant union types (e.g., "A" | "B" | ... | "Z" with hundreds of members).
Heavy infer usage inside generics.

✅ Tools

tsc --diagnostics → measure type-check performance.
tsc --extendedDiagnostics → detailed breakdown (parse time, check time, emit time).

🎯 One-Liner

“The biggest type-check killers are deep recursion, massive unions, and heavy conditional types — profile with --diagnostics.”

2. 🛠️ Avoiding Over-Complex Types

✅ Problem

Some teams abuse TS to encode too much at type level.

type Crazy<T> = T extends string 
  ? { str: T } 
  : T extends number 
    ? { num: T } 
    : never;

Hard to maintain, slows compiler.

✅ Guidelines

Keep types simple for DX (developer experience).
Don’t encode logic that belongs in runtime code.
Prefer branded/opaque types for safety, instead of extreme conditional gymnastics.

🎯 One-Liner

“Don’t over-engineer types — TS is for safety, not replacing runtime logic.”

3. 📦 Build Pipelines: `tsc` vs Babel vs SWC

✅ tsc

Full type-checker + emit.
Slowest, but canonical.

✅ Babel with `@babel/preset-typescript`

Strips types → no type-checking.
Fast, but must run tsc --noEmit separately.

✅ SWC (used in Next.js, Vite, Turborepo)

Rust-based transpiler, very fast.
Strips types only.

⚠️ Gotchas

Babel/SWC do not catch type errors — must run type-check separately in CI.

🎯 One-Liner

“Use SWC/Babel for fast builds, but keep tsc --noEmit in CI for type safety.”

4. 🔄 Incremental Compilation

✅ Options

"incremental": true in tsconfig.json → saves .tsbuildinfo cache.
"composite": true for project references (multi-package repos).

✅ Benefits

Only re-check changed files.
Required for monorepos with shared libraries.

🎯 One-Liner

“Enable incremental + composite in tsconfig to avoid full re-checks in large repos.”

5. 🧩 Project References (Scaling Monorepos)

Definition:
Break project into multiple sub-projects with clear build boundaries.

✅ Example

// tsconfig.json
{
  "files": [],
  "references": [
    { "path": "./packages/ui" },
    { "path": "./packages/server" }
  ]
}

✅ Benefits

Faster builds (independent packages).
Enforces dependency contracts.
Works great with Nx/Turborepo.

🎯 One-Liner

“Project references let you split large codebases into smaller typed units with enforced contracts.”

6. 🧠 Type-Only Imports & Exports (TS 3.8+)

✅ Example

import type { User } from "./types"; // stripped at runtime
export type { Config } from "./config";

✅ Benefits

Avoids accidentally bundling type-only modules.
Reduces unnecessary runtime imports.

🎯 One-Liner

“Use import type and export type to ensure pure type imports don’t affect runtime bundles.”

7. ⚖️ Managing `any` at Scale

✅ Problems

any spreads like a virus in codebases.
One any can propagate through dozens of types.

✅ Solutions

Use unknown instead of any when possible.
Use eslint rules (@typescript-eslint/no-explicit-any).
Introduce “escape hatches” (TODO: fix any) but track debt.

🎯 One-Liner

“Manage any aggressively — prefer unknown, enforce lint rules, and track escape hatches.”

8. 📊 Large Codebase Best Practices

✅ Strict mode always (strict: true).
✅ Type-only imports (import type).
✅ Use Zod/io-ts for runtime validation of API responses.
✅ Add tsc --noEmit in CI to enforce type safety.
✅ Use paths in tsconfig.json for clean imports.
✅ Monitor tsc --diagnostics to spot type-check slowdowns.

🎯 One-Liner

“Large TS projects succeed when strict mode, type-only imports, runtime validation, and CI type-checks are enforced.”

🟦 Ecosystem & Future

1. 🧩 Decorators (Stage 3 Proposal)

Definition:
Annotations for classes, methods, and properties.

✅ Example

function readonly(target: any, key: string) {
  Object.defineProperty(target, key, { writable: false });
}

class User {
  @readonly
  name = "Alice";
}

✅ Use Cases

Dependency injection (NestJS).
ORMs (TypeORM, Prisma).
Metadata reflection.

⚠️ Gotchas

Still experimental — syntax differs across versions.
Requires "experimentalDecorators": true in tsconfig.json.

🎯 One-Liner

“Decorators add metadata to classes/members — useful in frameworks like NestJS, but still experimental in TS.”

2. 📜 Type Annotations in JavaScript (TC39 Proposal)

Definition:
JavaScript itself may gain type syntax (stripped at runtime).

✅ Example (future JS)

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

Types would be ignored at runtime, like TS today.
TS would align with native JS type syntax.

🎯 One-Liner

“JS is moving toward built-in type annotations. TS will align, making gradual adoption easier.”

3. ⚖️ TypeScript vs Flow vs Others

✅ TypeScript

Mainstream, broad ecosystem.
Stronger tooling, VSCode integration.

✅ Flow (Meta)

Better type inference in theory.
Lost adoption due to ecosystem fragmentation.

✅ Elm / ReasonML / PureScript

Stronger type systems, but niche.

🎯 One-Liner

“TS won the ecosystem war — Flow and others have niche uses, but TS dominates frontend and Node.”

4. 🆕 New & Recent TS Features

✅ `satisfies` Operator (TS 4.9)

const theme = {
  primary: "blue",
  secondary: "red"
} satisfies Record<string, string>;

Ensures structure without widening values.

✅ `const` Type Parameters (coming soon)

function tuple<const T extends string[]>(...args: T): T {
  return args;
}
const t = tuple("a", "b"); // type ["a", "b"]

✅ Variance Annotations (future)

Explicitly mark generics as in (contravariant) or out (covariant).

🎯 One-Liner

“Features like satisfies and const generics improve precision without hacks — future TS is about better inference + clarity.”

5. 🏗️ Migration Strategies

✅ JS → TS

Enable allowJs + checkJs.
Rename .js → .ts gradually.
Add strict config (noImplicitAny, strictNullChecks).
Replace JSDoc with real types.

✅ Flow → TS

Use codemods (flow-to-ts).
Incrementally replace types.

✅ Legacy TS → Modern

Remove namespace in favor of ES modules.
Switch to strict mode.
Replace /// <reference> with proper imports.

🎯 One-Liner

“Migrate incrementally: JS → TS with checkJs, Flow → TS with codemods, legacy TS → strict modules.”

6. 🏢 TypeScript at Scale

✅ Observations

At very large scale (10M+ LOC), TS type-checking can bottleneck.
Some companies (Google, Meta) experiment with faster type-checkers (SWC, Rome, incremental builds).
Types become API contracts between teams — not just safety.

🎯 One-Liner

“At scale, TypeScript types are contracts between teams. Performance requires project references + incremental builds.”

7. 🔮 Future of TypeScript

✅ Trends

Closer alignment with JavaScript (native type annotations).
Better inference (const generics, variance).
Compiler performance improvements (Rust-based checkers like tsc-swc).
More runtime type-checking integration (Zod + TS).

🎯 One-Liner

“The future of TS is tighter JS integration, better inference, and faster compilers — runtime validation will bridge static gaps.”

✅ Summary (Full Handbook)

This TypeScript handbook covers staff/architect-level depth:

Fundamentals (type system vs runtime, primitives, assertions, narrowing, null checks, structural typing, interfaces vs types, enums vs literal types)
Advanced Types (unions, intersections, literals, const assertions, template literals, conditional, mapped, utility types, recursive types)
Generics (functions, constraints, defaults, keyof/indexed access, conditional generics, variance, HKTs, React generics)
Type Inference & Compatibility (inference, widening/narrowing, assignability, any vs unknown vs never, enums, tuples vs arrays)
JavaScript Interop (ambient declarations, @types, module augmentation, declaration merging, as const, tsconfig strictness, runtime validation, gradual migration)
Type Guards & Narrowing (typeof, instanceof, in-operator, discriminated unions, custom predicates, assertion functions, exhaustiveness checks)
Advanced Patterns (branded types, opaque types, recursive utilities, mapped utilities, variadic tuples, builder pattern, exact types, phantom types)
TypeScript in React (props, children, hooks, context, refs, HOCs, generic components, event handlers, polymorphic components)
Performance & Scaling (diagnostics, avoiding complex types, Babel/SWC vs tsc, incremental compilation, project references, import type, managing any, best practices)
Ecosystem & Future (decorators, JS type annotations proposal, TS vs Flow, new features like satisfies/const generics, migration strategies, TS at scale, future trends)

React Expert Revision Handbook

Animesh Pandey — Sun, 31 Aug 2025 19:16:01 +0000

📑 Table of Contents

React Core Fundamentals
State Management
Performance & Optimization
Advanced Hooks & Patterns
Concurrent Features & Architecture
React and the Browser
Large-Scale Application Architecture
React with Data & Networking
Testing & Quality
React Ecosystem & Future

🟦 React Core Fundamentals (Expert Level)

1. 🎭 Virtual DOM (VDOM)

Definition:
The Virtual DOM is a lightweight in-memory tree representation of the actual DOM. React diffs the VDOM against a previous version to compute the minimal set of changes and applies them to the real DOM.

✅ Key Points

Avoids expensive DOM mutations by batching and diffing.
Abstracts away browser DOM inconsistencies.
Works via reconciliation (diffing algorithm).

⚠️ Gotchas

VDOM is not always faster — for simple static pages, raw DOM is faster.
Frequent re-renders of large trees → reconciliation overhead.
DOM mutations inside useLayoutEffect or refs can bypass VDOM — can cause sync issues.

Example

// React maintains a virtual representation
<div className="item">Hello</div>

When state updates → React creates a new VDOM tree, diffs it with old, and mutates only changed nodes.

🎯 Interview One-Liner

“The Virtual DOM is React’s in-memory representation. It enables efficient diffs and minimal DOM updates, though reconciliation itself has cost.”

2. 🧮 Reconciliation Algorithm

Definition:
The process of comparing old and new VDOM trees to decide what to update in the real DOM.

✅ Diffing Rules

Elements of different types → destroy & recreate subtree.
Elements of same type → update props and recurse.
Lists → require keys for identity.

⚠️ Gotchas

Keys must be stable and unique. Index keys cause bugs if list reorders.
Changing key forces remount (state reset).
Deep trees may be skipped if React bails out early (e.g., shouldComponentUpdate or memo).

Example

{items.map(item => (
  <Item key={item.id} value={item.value} />
))}

🎯 Interview One-Liner

“Reconciliation compares old/new trees. Keys are critical — unstable keys break identity and cause unnecessary remounts.”

3. 🧵 React Fiber Architecture

Definition:
Fiber is React’s reimplementation of the reconciliation algorithm as a linked-list tree of work units, enabling incremental rendering and prioritization.

✅ Key Points

Fiber node = virtual stack frame (represents component & state).
Enables time slicing: pause/resume rendering.
Each update has a priority level (lane):
- High → user input.
- Low → background rendering.

⚠️ Gotchas

Fiber means React can pause rendering mid-tree and resume later. Side effects must only run in commit phase.
Updates may be interrupted and restarted — never rely on render being called exactly once per update.

Example (mental model)

Root Fiber → Child Fiber → Sibling Fiber
Each fiber has: type, pendingProps, memoizedState, return, child, sibling

🎯 Interview One-Liner

“Fiber is React’s linked-list architecture that enables pausing, resuming, and prioritizing work. Render is interruptible, commit is not.”

4. ⚙️ React Rendering Phases

Definition:
React rendering happens in two phases:

Render Phase (reconciliation):

Build Fiber tree, diff with old tree.
Pure & interruptible.

Commit Phase:

Apply DOM mutations.
Run layout effects (useLayoutEffect).
Trigger lifecycles.
Synchronous & non-interruptible.

⚠️ Gotchas

Render can run multiple times per update (especially in StrictMode).
Side effects must not run in render phase (causes bugs in concurrent mode).
Layout effects block paint until executed.

🎯 Interview One-Liner

“Render is pure and may be interrupted or restarted. Commit applies changes to the DOM and always runs synchronously.”

5. ⏳ Component Lifecycle (Class vs Hooks)

✅ Class Lifecycle

Mount: constructor → render → componentDidMount
Update: render → componentDidUpdate
Unmount: componentWillUnmount

✅ Hook Equivalents

useEffect → componentDidMount/Update (async, after paint).
useLayoutEffect → sync after DOM mutation, before paint.
useEffect cleanup / useLayoutEffect cleanup → componentWillUnmount.

⚠️ Gotchas

StrictMode double-invokes lifecycle methods in dev.
useEffect runs after paint → may cause flicker for measurements.
useLayoutEffect blocks paint → don’t overuse.

🎯 Interview One-Liner

“Class lifecycle maps to hooks. useEffect runs async after paint, useLayoutEffect runs sync before paint. Use the latter sparingly for DOM measurements.”

6. 📜 Rules of Hooks

Definition:
Hooks must be called at the top level of a component or custom hook.

✅ Rules

Only call hooks in React functions.
Always call hooks in the same order.

Why?

Hooks rely on array-like ordering in Fiber.
Violations break hook state tracking.

⚠️ Gotchas

Conditional hooks → break order.
Loops with hooks → break order.

Example

// ❌ Wrong
if (cond) useState(1);

// ✅ Right
const [x, setX] = useState(1);
if (cond) { ... }

🎯 Interview One-Liner

“Hooks are tracked by call order, not names. That’s why they must run unconditionally at the top level.”

7. 🎛️ Context API Internals

Definition:
Provides a way to pass values deeply without prop drilling.

✅ Key Points

Uses a Provider + Consumer (or useContext).
Each Context has its own Fiber subscription list.
Any value change triggers re-render for all consumers, unless optimized.

⚠️ Gotchas

Performance pitfall: Every consumer re-renders even if not using changed parts.
Fix: split contexts, use memoized values, or libraries like Zustand.
Don’t store derived values in Context unnecessarily (causes extra re-renders).

Example

const ThemeContext = React.createContext();
function App() {
  return <ThemeContext.Provider value="dark"><Child /></ThemeContext.Provider>
}

🎯 Interview One-Liner

“Context avoids prop drilling but re-renders all consumers on change. Optimize with memoized values or split contexts.”

8. 🎹 Controlled vs Uncontrolled Components

Definition:

Controlled: Form input state lives in React.
Uncontrolled: Input state lives in DOM, accessed via refs.

✅ Tradeoffs

Controlled → easier validation, predictable state, re-render cost.
Uncontrolled → better performance, harder validation.

⚠️ Gotchas

Mixing controlled/uncontrolled on same input → React warning.
Controlled components must update value on every change.

Example

// Controlled
<input value={value} onChange={e => setValue(e.target.value)} />

// Uncontrolled
<input defaultValue="hello" ref={ref} />

🎯 Interview One-Liner

“Controlled inputs sync state to React, while uncontrolled rely on the DOM. Controlled are predictable but heavier.”

🟦 State Management (Built-in + External)

1. 🎛️ `useState` vs `useReducer`

✅ `useState`

Simple state, single value updates.
Good for UI-local state (inputs, toggles).
Updates replace state, not merge.

✅ `useReducer`

More structured, centralizes update logic.
Better for complex transitions or state machines.
Reducer function makes updates predictable (pure).

⚠️ Gotchas

setState is async but batched in React 18.
Stale closures if accessing state in async callbacks.
useReducer is stable across re-renders → avoids dependency hell.

Example

function counterReducer(state, action) {
  switch (action.type) {
    case "inc": return { count: state.count + 1 };
    case "dec": return { count: state.count - 1 };
    default: return state;
  }
}
const [state, dispatch] = useReducer(counterReducer, { count: 0 });

🎯 Interview One-Liner

“Use useState for simple, isolated state. Use useReducer when state transitions are complex or when debugging predictability matters.”

2. 🌐 Local vs Global State

✅ Local State

Component-specific (UI interactions).
Keep as local as possible for performance & maintainability.

✅ Global State

Shared across large parts of the app (auth, theme, user data).
Can cause over-rendering if managed poorly.

⚠️ Gotchas

Overusing global state → hard to reason about.
Storing derived values globally → redundant re-renders.

🎯 Interview One-Liner

“Keep state as local as possible. Promote to global only when multiple areas need it — overusing global state makes debugging harder.”

3. 📦 Context API for State

✅ Key Points

Good for low-frequency global state (theme, auth, i18n).
Bad for high-frequency updates (chat messages, real-time counters).

⚠️ Performance Pitfall

Any value change re-renders all consumers, even if they don’t use the changed fields.

Fixes

Split contexts by domain (AuthContext, ThemeContext).
Use memoized values:

<AuthContext.Provider value={useMemo(() => ({user, login}), [user])}>

Use selector libraries (Zustand, Jotai).

🎯 Interview One-Liner

“Context works for low-frequency global state, but high-frequency updates cause over-renders. Fix with memoization, splitting, or external stores.”

4. 🗃️ Redux

✅ Strengths

Predictable state container (single source of truth).
Strict unidirectional data flow.
Great for debugging (Redux DevTools, time travel).

⚠️ Weaknesses

Boilerplate-heavy (reducers, actions).
Overkill for small apps.
Frequent re-renders unless using selectors.

Modern Redux (RTK)

Redux Toolkit simplifies boilerplate.
Immer for immutable updates.
Built-in async thunks.

🎯 Interview One-Liner

“Redux provides predictable global state with time-travel debugging. Modern RTK removes boilerplate and uses Immer for immutability.”

5. 🧵 Zustand, Recoil, Jotai (Modern State Libraries)

✅ Zustand

Minimal, no boilerplate.
Store is just a hook:

const useStore = create(set => ({ count: 0, inc: () => set(s => ({ count: s.count+1 })) }));

Fine-grained reactivity (components subscribe to slices).

✅ Recoil

Atom-based (pieces of state are independent).
Derived values via selectors.
Plays well with concurrent rendering.

✅ Jotai

Primitive atoms (similar to Recoil, simpler).
Directly use hooks for atom state.

🎯 Interview One-Liner

“Modern libraries like Zustand and Recoil fix Context’s perf issues by letting components subscribe to slices of state instead of the whole store.”

6. 🧩 Event-Driven vs Snapshot State

✅ Snapshot (React default)

You always render the latest snapshot.
Changes trigger a re-render.

✅ Event-driven (rare but useful)

Instead of syncing state → broadcast events (pub/sub).
Useful for real-time apps (chat, notifications).

🎯 Interview One-Liner

“React state is snapshot-based. For real-time event-driven scenarios, combine with pub/sub systems to avoid re-render storms.”

7. 🗄️ Normalized State

Definition:

Represent relational data in flat structures (like a database).

✅ Why

Avoids deep nested updates.
Improves memoization (can compare by ID).

Example

// ❌ Nested
state = { users: [{ id: 1, posts: [{id: 5}]}] };

// ✅ Normalized
state = { users: {1: {id:1, posts:[5]}}, posts: {5: {...}} };

Tools

Redux Toolkit’s createEntityAdapter.
Normalizr library.

🎯 Interview One-Liner

“Normalize relational state to flat structures. This avoids deep updates and enables efficient memoization.”

8. 🧊 Immutable Updates

Definition:

React state must not be mutated directly — immutability ensures predictable diffs.

✅ Tools

Spread operator, Object.assign.
Immer (used by Redux Toolkit).

⚠️ Gotchas

// ❌ Mutation
state.user.name = "Alex"; 

// ✅ Immutable update
state = { ...state, user: { ...state.user, name: "Alex" } };

🎯 Interview One-Liner

“React relies on immutability to detect changes. Mutating state directly breaks reactivity and can cause stale renders.”

🟦 Performance & Optimization

1. 🧭 Understanding Re-Renders

Definition:
A component re-renders when its state or props change, or when its parent re-renders and passes new references.

✅ Key Points

React compares new vs old VDOM → reconciles differences.
Even if output is identical, reconciliation still happens.
Render ≠ always commit (render can be interrupted).

⚠️ Gotchas

Passing new object/array literals causes re-renders:

<MyComp data={{x:1}} /> // new object each render

Context updates re-render all consumers.
React.memo prevents re-render only if props shallow-equal.

🎯 Interview One-Liner

“Re-renders happen on state/prop changes or parent updates. Passing new object references or Context changes are common perf killers.”

2. 🪞 React.memo, useMemo, useCallback

✅ React.memo

Wraps component → shallowly compares props.
Prevents unnecessary re-renders.

✅ useMemo

Memoizes values between renders.
Expensive computations or derived values.

✅ useCallback

Memoizes functions → prevents creating new fn refs.
Useful when passing callbacks to memoized children.

⚠️ Gotchas

useMemo/useCallback themselves add cost — only use when necessary.
Shallow comparison means nested objects still cause false negatives.
Over-memoization can worsen performance.

🎯 Interview One-Liner

“React.memo avoids re-renders by shallow prop compare. useMemo memoizes values, useCallback memoizes functions. Overusing them can hurt, not help.”

3. 🔄 Batching Updates

Definition:
React groups multiple state updates into one render.

✅ Before React 18

Batching happened only inside event handlers.

✅ React 18+

Batching happens in all contexts (timers, async callbacks, promises).

Example

setCount(c => c+1);
setValue(v => v+1);
// React 18 → one render

🎯 Interview One-Liner

“React 18 enables automatic batching everywhere, reducing re-renders. Before 18, batching was limited to event handlers.”

4. ⚡ Concurrent Rendering

Definition:
React 18’s Concurrent Mode (enabled by default) allows rendering to be interruptible, paused, or restarted based on priority.

✅ Key Points

Enables time slicing — responsive UI during rendering.
New APIs: useTransition, useDeferredValue.
Doesn’t change final UI, just how React schedules updates.

⚠️ Gotchas

Render can happen multiple times before commit.
Side effects must be in commit phase (useEffect, not render).

🎯 Interview One-Liner

“Concurrent rendering lets React pause and resume work based on priority. It doesn’t change the UI outcome, only the scheduling.”

5. 🕹️ useTransition & useDeferredValue

✅ useTransition

Splits updates into urgent vs non-urgent.
Keeps UI responsive during heavy re-renders.

const [isPending, startTransition] = useTransition();
startTransition(() => setSearchResults(expensiveCompute(query)));

✅ useDeferredValue

Defers updating a value until less urgent work is done.

const deferredQuery = useDeferredValue(query);

🎯 Interview One-Liner

“useTransition marks updates as non-urgent, keeping UI responsive. useDeferredValue delays expensive renders until idle.”

6. 📦 Virtualization (Large Lists)

Definition:
Render only visible items in a list instead of all at once.

✅ Libraries

react-window, react-virtualized.

✅ Benefits

Huge perf gains for 10k+ items.
Reduces DOM nodes drastically.

⚠️ Gotchas

Needs correct height calculation.
Accessibility and SEO challenges (hidden elements not available).

🎯 Interview One-Liner

“Virtualization renders only visible list items. Essential for huge datasets, but requires careful handling of heights and accessibility.”

7. 🎭 Suspense for Data Fetching

Definition:
Suspense lets components “wait” for async data before rendering fallback UI.

✅ Key Points

Suspense boundaries prevent waterfalls.
Used with React 18 data frameworks (Next.js, Relay).
Works with streaming SSR.

⚠️ Gotchas

Suspense only handles promises, not arbitrary async.
Error handling must use Error Boundaries.

🎯 Interview One-Liner

“Suspense lets React wait for async data with fallbacks. It simplifies async UI but needs Error Boundaries for failure cases.”

8. 🧩 Avoiding Expensive Renders

✅ Techniques

Windowing/virtualization for long lists.
Throttling/debouncing user input.
Lazy load components (React.lazy).
Selective Context (split providers).
Selector hooks (subscribe to slices of state).

🎯 Interview One-Liner

“Optimize renders by memoizing, windowing lists, debouncing inputs, lazy loading code, and splitting state into smaller contexts.”

9. 📊 Debugging Performance

✅ Tools

React DevTools Profiler (flame graph of renders).
why-did-you-render library (detects unnecessary renders).
Browser Performance tab.

✅ Common Symptoms

Re-render storms.
Input lag.
Flickering UI.

🎯 Interview One-Liner

“Use React Profiler and why-did-you-render to spot re-render storms. Input lag or flickering often means wasted renders.”

🟦 Advanced Hooks & Patterns

1. 🛠️ Custom Hooks (Encapsulation & Reuse)

Definition:

Custom hooks are user-defined functions that use other hooks to encapsulate reusable logic.

✅ Key Points

Encapsulate side effects, subscriptions, state machines.
Return values (state, handlers) just like built-ins.
Naming convention: useSomething ensures linting rules apply.

Example

function useOnlineStatus() {
  const [online, setOnline] = useState(navigator.onLine);
  useEffect(() => {
    const update = () => setOnline(navigator.onLine);
    window.addEventListener("online", update);
    window.addEventListener("offline", update);
    return () => {
      window.removeEventListener("online", update);
      window.removeEventListener("offline", update);
    };
  }, []);
  return online;
}

🎯 Interview One-Liner

“Custom hooks let you extract reusable stateful logic. They’re just functions that call hooks and return state/handlers.”

2. 🧮 Hook Composition vs HOCs vs Render Props

✅ Higher-Order Components (HOCs)

Function that wraps a component → returns new component.
Used for cross-cutting concerns (auth, logging).

✅ Render Props

Component accepts a function as children or prop → renders custom UI.

✅ Hooks

Modern replacement for both — composable, less nesting.

⚠️ Gotchas

HOCs increase component tree depth (“wrapper hell”).
Render props cause “function as child” nesting.
Hooks keep tree flat but can cause dependency confusion in useEffect.

🎯 Interview One-Liner

“Hooks replace HOCs and Render Props for reusing logic. They’re flatter and composable, but you must manage dependencies carefully.”

3. 🧩 Compound Components Pattern

Definition:

Builds components that work together as a set, sharing state via Context or props.

✅ Example

function Tabs({ children }) {
  const [active, setActive] = useState(0);
  return (
    <TabsContext.Provider value={{active, setActive}}>
      {children}
    </TabsContext.Provider>
  );
}
function TabList({ children }) { return <div>{children}</div>; }
function Tab({ index, children }) {
  const {active, setActive} = useContext(TabsContext);
  return <button onClick={() => setActive(index)}>{children} {active === index && "*"}</button>;
}

✅ Benefits

Great for design systems.
Flexible API (consumer composes layout).

🎯 Interview One-Liner

“Compound components let you build flexible APIs where multiple components share context state, like Tabs, Accordions, or Menus.”

4. 🧮 Controlled vs Uncontrolled Components (Revisited)

Controlled → Parent owns state.
Uncontrolled → DOM owns state (access via ref).

✅ Pattern

Some advanced components support both via value + defaultValue.

Example

function Input({ value, defaultValue, onChange }) {
  const [internal, setInternal] = useState(defaultValue || "");
  const isControlled = value !== undefined;
  const val = isControlled ? value : internal;

  function handleChange(e) {
    if (!isControlled) setInternal(e.target.value);
    onChange?.(e);
  }
  return <input value={val} onChange={handleChange} />;
}

🎯 Interview One-Liner

“Controlled components sync state to React, uncontrolled use refs. Advanced components often support both by checking for value prop.”

5. 🔗 Prop Getters Pattern

Definition:

A function returns props you spread onto elements, letting consumers extend behavior.

✅ Example

function useToggle() {
  const [on, setOn] = useState(false);
  const toggle = () => setOn(o => !o);
  function getTogglerProps(props = {}) {
    return {
      "aria-pressed": on,
      onClick: (e) => { props.onClick?.(e); toggle(); },
      ...props
    };
  }
  return { on, getTogglerProps };
}

Usage:

const { on, getTogglerProps } = useToggle();
<button {...getTogglerProps({ onClick: () => console.log("clicked") })}>
  {on ? "On" : "Off"}
</button>

🎯 Interview One-Liner

“Prop Getters let custom hooks merge consumer props with internal behavior — ensuring accessibility and extensibility.”

6. 🎛️ Refs & Imperative APIs

✅ useRef

Holds mutable values across renders without triggering re-renders.
Common for DOM access.

✅ forwardRef

Lets parent pass refs down to child components.

✅ useImperativeHandle

Expose custom methods from a component via ref.

Example

const FancyInput = forwardRef((props, ref) => {
  const inputRef = useRef();
  useImperativeHandle(ref, () => ({
    focus: () => inputRef.current.focus()
  }));
  return <input ref={inputRef} {...props} />;
});

const ref = useRef();
<FancyInput ref={ref} />;
ref.current.focus();

🎯 Interview One-Liner

“Refs provide imperative escapes. forwardRef passes refs down, useImperativeHandle customizes exposed APIs.”

7. ⏱️ useEffect vs useLayoutEffect

✅ useEffect

Runs after paint → async, non-blocking.
Good for subscriptions, async calls.

✅ useLayoutEffect

Runs synchronously after DOM mutations but before paint.
Good for DOM measurements, sync mutations.

⚠️ Gotchas

Using useLayoutEffect for heavy work blocks paint → jank.
Server-side rendering warns if you use useLayoutEffect (no DOM).

🎯 Interview One-Liner

“useEffect runs async after paint; useLayoutEffect runs sync before paint — use the latter only for DOM measurements.”

8. 🛡️ Error Boundaries

Definition:

React components that catch errors in children and render fallback UI.

✅ Key Points

Class components only (componentDidCatch).
Catch render, lifecycle, commit errors.
Don’t catch async errors (use try/catch in async).

Example

class ErrorBoundary extends React.Component {
  state = { hasError: false };
  static getDerivedStateFromError() { return { hasError: true }; }
  componentDidCatch(error, info) { console.log(error, info); }
  render() { return this.state.hasError ? <h1>Oops</h1> : this.props.children; }
}

🎯 Interview One-Liner

“Error Boundaries catch render/lifecycle errors in children and show fallback UI. They don’t catch async errors or event handlers.”

🟦 React Concurrent Features & Architecture

1. 🧵 Fiber Deep Dive

Definition:
Fiber is React’s internal data structure (a linked list of “units of work”) that enables interruptible, prioritized rendering.

✅ Key Points

Fiber Node stores:
- type (component/function)
- pendingProps, memoizedState
- child, sibling, return pointers (tree shape)
Enables React to pause rendering mid-tree, yield to higher-priority work, then resume.
Each Fiber node corresponds to one component instance.

⚠️ Gotchas

Render can be restarted — never rely on render running exactly once.
Effects must run in commit phase, not render.
Updates can be reordered for performance (concurrent mode).

🎯 Interview One-Liner

“Fiber is React’s linked-list tree of work units. It makes rendering interruptible, resumable, and prioritizable.”

2. 🛣️ Lanes & Scheduling (React 18)

Definition:
React assigns updates to lanes — priority buckets for scheduling work.

✅ Key Points

Urgent → user input (click, typing).
Normal → data updates.
Idle → background rendering.
React merges lanes when possible to batch updates.

⚠️ Gotchas

Updates may not flush immediately — React may wait until a higher-priority update occurs.
Debugging lag requires understanding scheduling lanes.

🎯 Interview One-Liner

“React uses lanes to schedule updates by priority. User input gets high priority, background renders get low. This keeps apps responsive.”

3. ⏳ Render vs Commit (Revisited)

Render phase
- Build Fiber tree, diff with previous.
- Interruptible.
- No DOM mutations.
Commit phase
- Apply DOM changes.
- Run layout effects & lifecycles.
- Non-interruptible.

⚠️ Gotchas

StrictMode can trigger double-invoked renders to expose side effects.
Commit phase runs synchronously — avoid blocking.

🎯 Interview One-Liner

“Render is interruptible and pure, commit is synchronous and mutates the DOM. All side effects belong in commit.”

4. ⏱️ Concurrent Rendering

Definition:
Introduced in React 18: rendering is no longer “all or nothing”. React can pause, resume, restart renders.

✅ Benefits

Keeps input responsive during heavy rendering.
Splits urgent vs non-urgent updates.
Enables new APIs (useTransition, useDeferredValue).

⚠️ Gotchas

Component render functions can run multiple times without committing.
Must avoid side effects in render (or cause bugs).

🎯 Interview One-Liner

“Concurrent rendering lets React pause and resume work. This keeps UIs responsive but means renders can restart anytime.”

5. 🕹️ Transition API

✅ useTransition

Marks state updates as non-urgent.
Keeps urgent work (typing, clicks) responsive.

const [isPending, startTransition] = useTransition();
startTransition(() => {
  setSearchResults(expensiveQuery(query));
});

✅ useDeferredValue

Defers value updates until React is idle.

const deferredQuery = useDeferredValue(query);

🎯 Interview One-Liner

“useTransition splits urgent vs non-urgent updates. useDeferredValue delays heavy computations until idle.”

6. 📦 Suspense for Data (React 18+)

Definition:
Suspense boundaries allow components to wait for promises before rendering fallback UI.

✅ Key Points

Works with streaming SSR.
Integrates with frameworks like Next.js (app router).
Prevents waterfalls by suspending at boundaries.

⚠️ Gotchas

Suspense doesn’t handle errors → must use Error Boundaries.
Data fetching must throw a promise to suspend (React Query, Relay do this).

Example

<Suspense fallback={<Spinner />}>
  <Profile />
</Suspense>

🎯 Interview One-Liner

“Suspense lets React pause rendering for async data, showing fallback UI. It simplifies async orchestration in concurrent rendering.”

7. 🌐 Streaming SSR & Suspense

Definition:
React 18 added streaming server rendering with Suspense support.

✅ Key Points

Server sends HTML chunks progressively.
Suspense boundaries can stream in later.
Improves TTFB (time to first byte).

⚠️ Gotchas

Requires careful hydration (client must resume correctly).
Progressive hydration needed to avoid blocking interactivity.

🎯 Interview One-Liner

“Streaming SSR sends HTML in chunks with Suspense boundaries, improving TTFB and avoiding full-page blocking.”

8. 🧑‍💻 React Server Components (RSC)

Definition:
New model where some components render on the server only.

✅ Key Points

RSCs don’t ship JS to client → smaller bundles.
Can fetch data directly (no hooks).
Can stream into client tree.

⚠️ Gotchas

Server & client components must be carefully separated.
Not fully mature outside Next.js App Router yet.

🎯 Interview One-Liner

“React Server Components let some components render only on the server, reducing client JS and enabling data-fetching at the component level.”

9. 🧩 Hydration & Variants

Definition:
Hydration = React attaches event listeners to server-rendered HTML.

✅ Variants

Partial Hydration → only hydrate interactive parts.
Islands Architecture → hydrate independent sections separately.
Selective Hydration (React 18) → React hydrates higher-priority parts first.

⚠️ Gotchas

Mismatch between server/client markup → hydration errors.
Must ensure deterministic render output.

🎯 Interview One-Liner

“Hydration attaches React to server HTML. React 18 does selective hydration, hydrating high-priority parts first.”

10. ⚙️ React Compiler (Meta’s new optimization)

Definition:
Upcoming optimization that auto-memoizes components by analyzing dependencies.

✅ Key Points

Removes manual useMemo / useCallback needs.
Still experimental, but already used internally at Meta.

🎯 Interview One-Liner

“React Compiler automatically memoizes components by analyzing dependencies, reducing the need for manual useMemo/useCallback.”

🟦 React and the Browser

1. 🎯 React’s Synthetic Event System

Definition:
React wraps native browser events in a SyntheticEvent object for consistency across browsers.

✅ Key Points

React normalizes event names/behavior.
Events are pooled for performance (object reused).
Handlers receive the synthetic event, not the native one.
If you need the native event → use event.nativeEvent.

⚠️ Gotchas

Event pooling can cause bugs:

function handleClick(e) {
  setTimeout(() => console.log(e.type)); // ❌ e is null (pooled)
}

Fix:

e.persist(); // prevents pooling

Since React 17+, event delegation attaches at the root container, not document.

🎯 Interview One-Liner

“React wraps events in a SyntheticEvent for cross-browser consistency. They’re pooled by default, so use e.persist() if async access is needed.”

2. 🪟 Portals

Definition:
Portals allow rendering children into a DOM node outside the parent hierarchy.

✅ Use Cases

Modals, tooltips, dropdowns (avoid z-index hell).
Fixed-position UI that must escape overflow/position contexts.

⚠️ Gotchas

Events still bubble through React tree, not DOM hierarchy.
CSS scoping issues: portal content may escape styling context.

Example

ReactDOM.createPortal(<Modal />, document.getElementById("modal-root"));

🎯 Interview One-Liner

“Portals let you render components outside parent DOM hierarchy but keep React’s event bubbling intact. Ideal for modals & tooltips.”

3. ⏱️ Concurrent Input Handling

Definition:
React 18 uses concurrent rendering to keep inputs responsive during heavy updates.

✅ Patterns

useTransition: defer expensive UI while typing remains smooth.
Debouncing or throttling input handlers.
Offload expensive work to Web Workers if needed.

⚠️ Gotchas

Without transitions, large lists can lag when filtering.
Transition fallback (isPending) must show loading state gracefully.

🎯 Interview One-Liner

“Concurrent input handling keeps typing responsive during heavy renders using transitions, deferrals, and sometimes workers.”

4. 🎨 CSS-in-React Strategies

✅ Options

CSS Modules → Scoped per file, no runtime cost.
CSS-in-JS (styled-components, Emotion) → Dynamic styling, runtime overhead.
Utility-first (Tailwind) → Atomic classes, fast builds.
Vanilla Extract, Linaria → Zero-runtime CSS-in-JS.

✅ Performance Considerations

CSS-in-JS creates runtime overhead (inserts <style> at runtime).
Tailwind/atomic CSS minimizes runtime but can bloat HTML.
CSS Modules = simple & performant default.

🎯 Interview One-Liner

“CSS-in-React strategies vary: CSS Modules are simple & fast, CSS-in-JS offers flexibility with runtime cost, Tailwind optimizes for dev speed.”

5. ♿ Accessibility (a11y)

Definition:
Ensuring UI works for all users, including assistive technologies.

✅ Key Points

Use semantic HTML (<button> instead of <div onClick>).
ARIA roles and attributes for assistive tools.
Keyboard navigation (tab order, focus management).
Color contrast compliance (WCAG AA/AAA).
aria-live regions for async updates.

⚠️ Gotchas

Custom components (e.g., <div role="button">) require manual keyboard handlers.
Portals can trap focus if modals don’t manage it.

Example

<button aria-pressed={on}>Toggle</button>

🎯 Interview One-Liner

“Accessible React means using semantic HTML, ARIA attributes, and proper focus management. Accessibility isn’t optional at scale.”

6. ⚡ Browser APIs in React

✅ Common Integrations

IntersectionObserver → lazy load images, infinite scroll.
ResizeObserver → adapt to element size changes.
MutationObserver → detect DOM mutations.
requestIdleCallback → schedule background work.

⚠️ Gotchas

Must clean up observers in useEffect cleanup.
Observers fire frequently → debounce or throttle updates.

🎯 Interview One-Liner

“React integrates with browser observers (Intersection, Resize, Mutation) for performance-sensitive UIs. Always clean up listeners.”

7. 🧩 Browser Rendering vs React Rendering

✅ Browser Rendering

HTML → DOM → CSSOM → Render Tree → Layout → Paint → Composite.

✅ React Rendering

VDOM diff → Fiber scheduling → Commit → DOM mutation → Browser rendering pipeline.

⚠️ Gotchas

React may skip DOM updates if VDOM diff sees no changes.
But every render still costs JS time → optimize unnecessary renders.

🎯 Interview One-Liner

“Browser rendering = layout/paint. React rendering = VDOM diff → DOM mutation. Both must be optimized separately.”

🟦 Large-Scale React Application Architecture

1. 🧱 Component-Driven Development (CDD)

Definition:
Build applications from small reusable components upward, using a design system.

✅ Key Points

Atomic Design: Atoms → Molecules → Organisms → Templates → Pages.
Storybook or Ladle for component isolation.
Components must be stateless + composable where possible.

⚠️ Gotchas

Too much abstraction leads to “prop soup.”
Teams must align on design tokens (spacing, colors, typography).

🎯 Interview One-Liner

“CDD means building from reusable components, often with a design system, to scale consistency across teams.”

2. 🎨 Multi-Tenant Theming

Definition:
Supporting multiple brands or tenants from the same codebase.

✅ Techniques

CSS Variables: Themeable at runtime:

:root { --primary: blue; }
[data-theme="dark"] { --primary: black; }

<button style={{ color: "var(--primary)" }}>Click</button>

Context Providers: Provide theme object via React context.
Design Tokens: Abstract theme into JSON tokens → consumed by CSS-in-JS, CSS vars, or native CSS.

⚠️ Gotchas

Context re-renders on theme switch.
Dynamic imports for brand assets.
Multi-tenant SSR must inject correct theme per request.

🎯 Interview One-Liner

“Multi-tenant theming is solved with design tokens + CSS variables, allowing runtime theme switching without rebuilds.”

3. 🗂️ Monorepos & Code Sharing

✅ Approaches

Turborepo / Nx: Efficient build & caching.
Yarn Workspaces / pnpm Workspaces: Share deps.
Component packages: Internal NPM libraries for design system.

⚠️ Gotchas

Dependency hoisting issues.
Cross-package version drift.
Need CI/CD pipelines that handle partial builds.

🎯 Interview One-Liner

“Monorepos with tools like Nx/Turborepo enable shared design systems and libraries, but need caching and dependency management.”

4. 🌍 Micro-Frontends (Module Federation)

Definition:
Splitting large apps into independently deployable React apps.

✅ Key Points

Webpack Module Federation: load remote components at runtime.
Teams deploy independently, reducing coordination.
Shared dependencies (React, design system) must be singleton.

⚠️ Gotchas

Cross-microfrontend routing.
State sharing between MFEs is tricky.
Performance hit if federation is misconfigured (duplicate Reacts!).

🎯 Interview One-Liner

“Micro-frontends split large React apps into independently deployable modules, often via Module Federation. Great for org scaling, tricky for state & routing.”

5. 🛡️ Error Boundaries at Scale

✅ Patterns

Wrap critical UI chunks (e.g., dashboard widgets).
Provide segmented recovery → one widget fails, rest continue.
Show fallback UI with retry.

Example

<ErrorBoundary fallback={<RetryButton />}>
  <Widget />
</ErrorBoundary>

⚠️ Gotchas

Don’t wrap the whole app with one boundary — loses isolation.
Errors in async code aren’t caught.

🎯 Interview One-Liner

“At scale, error boundaries must isolate failures per feature, ensuring one broken widget doesn’t take down the entire app.”

6. 📊 Logging, Monitoring, Observability

✅ Key Points

Frontend Observability includes:
- Error tracking (Sentry, Datadog, New Relic).
- Performance metrics (LCP, FID/INP, CLS).
- User interactions (heatmaps, logs).
Centralized logging pipeline → correlate frontend errors with backend logs.

⚠️ Gotchas

GDPR/PII compliance: don’t log sensitive data.
Sampling needed at scale (don’t log every keystroke).

🎯 Interview One-Liner

“Frontend observability at scale means error tracking + performance metrics + logs, tied to backend systems. Logging must respect privacy laws.”

7. 🔒 Security in React Apps

✅ Common Threats

XSS (Cross-Site Scripting):
- Avoid dangerouslySetInnerHTML.
- Sanitize user input (DOMPurify).
CSRF (Cross-Site Request Forgery):
- Use SameSite cookies or CSRF tokens.
Clickjacking:
- X-Frame-Options headers.
Dependency vulnerabilities:
- Regular audits with npm audit, Snyk.

⚠️ Gotchas

Don’t trust client-side validation → always validate server-side.
Don’t roll your own sanitizer.

🎯 Interview One-Liner

“React itself mitigates XSS by escaping content, but security requires sanitizing inputs, protecting cookies, and hardening dependencies.”

8. 🏗️ Scalability Best Practices

Code splitting → lazy load per route.
Component boundaries → minimize prop drilling, use context sparingly.
Selective hydration → hydrate only critical UI.
Consistent architecture → enforce with ESLint + TypeScript.
Team-level contracts → clear ownership of shared libraries.

🎯 Interview One-Liner

“Scaling React apps requires modular architecture, code splitting, selective hydration, and strong governance over shared libraries.”

🟦 React with Data & Networking

1. 📡 Data Fetching Strategies

✅ Approaches

Manual fetch in useEffect

Simple, but prone to race conditions & missing caching.
1. Global fetchers (React Query, SWR, Apollo)
Cache + deduplication + retries built-in.
1. Server Components (RSC)
Data fetched on the server → no client fetch needed.

⚠️ Gotchas

useEffect(fetch) → risks double-fetch in StrictMode.
Must abort stale requests (AbortController).
Data fetching belongs outside render → don’t fetch inside components without memoization.

🎯 Interview One-Liner

“Manual fetching works for small apps, but React Query/SWR handle caching, retries, deduplication. RSC moves fetching server-side.”

2. 🗃️ Caching Approaches

✅ Snapshot Cache (React Query, SWR)

Store last response in cache.
Deduplicate identical queries.
Stale-while-revalidate pattern:
- Show cached data immediately.
- Refresh in background.

✅ Normalized Cache (Apollo, Relay)

Cache data by entity ID (like a client-side DB).
Avoids duplicate entities in memory.

⚠️ Gotchas

Normalized caching = more boilerplate.
Snapshot caching = easier, but duplicates possible.

🎯 Interview One-Liner

“Snapshot caches store responses; normalized caches deduplicate entities by ID. Use normalized caching when relational data needs consistency.”

3. 🕹️ Suspense for Data Fetching

Definition:
React Suspense lets components “pause” until a Promise resolves.

✅ Key Points

Works with data libraries that throw promises.
Boundaries prevent waterfall loading.
Enables streaming SSR.

⚠️ Gotchas

Must combine with Error Boundaries.
Not production-ready for all cases yet (needs framework support).

Example

<Suspense fallback={<Spinner />}>
  <Profile />
</Suspense>

🎯 Interview One-Liner

“Suspense lets components wait for promises, showing fallbacks instead of loaders everywhere.”

4. 🔄 Optimistic UI & Rollbacks

Definition:
Update the UI immediately on user action, then reconcile with server response.

✅ Key Points

Increases responsiveness.
Requires rollback if server rejects update.

Example (React Query)

mutate(newTodo, {
  optimisticUpdate: cache => [...cache, newTodo],
  onError: (err, _, rollback) => rollback(),
});

⚠️ Gotchas

Rollbacks must restore consistent state.
Concurrency issues if multiple mutations overlap.

🎯 Interview One-Liner

“Optimistic UI updates immediately for responsiveness, but requires rollback on failure. Libraries like React Query automate this.”

5. 🌊 Streaming Data (Realtime)

✅ Approaches

WebSockets: Full-duplex, bidirectional.
Server-Sent Events (SSE): One-way streaming from server → client.
GraphQL Subscriptions: Built on WebSockets.

✅ React Integration

Store messages in state or external store (Zustand).
Use Suspense for initial load, event-driven updates after.

⚠️ Gotchas

Must handle reconnects.
Avoid memory leaks by unsubscribing on unmount.
Overusing Context for streaming data → re-renders every message.

🎯 Interview One-Liner

“Real-time data uses WebSockets, SSE, or GraphQL subscriptions. Integrate with React using stores or selectors to avoid re-render storms.”

6. ⚠️ Handling Race Conditions

✅ Problem

If a user types quickly, multiple fetches may return out of order.

✅ Solutions

AbortController: cancel stale requests.
Latest-only strategy: track request ID.
Data libraries: React Query handles deduplication.

Example

const controller = new AbortController();
fetch("/api?q=term", { signal: controller.signal });
controller.abort(); // cancel previous request

🎯 Interview One-Liner

“Prevent race conditions by aborting stale requests (AbortController) or using libraries with deduplication.”

7. 🧩 Error Handling in Data

✅ Patterns

Wrap fetches with Error Boundaries.
Show segmented error UI (not one giant crash).
Retry with exponential backoff.

Example (React Query)

useQuery("todos", fetchTodos, { retry: 3, retryDelay: 2000 });

🎯 Interview One-Liner

“Handle data errors gracefully: retries, error boundaries, and segmented fallback UI.”

8. ⚡ Data Prefetching & Dehydration

✅ Prefetching

Fetch data before navigation → instant page load.
Frameworks like Next.js, Remix automate this.

✅ Dehydration

Server fetches data → serializes into HTML → client hydrates cache.

🎯 Interview One-Liner

“Prefetching and dehydration make data instantly available on navigation by preloading or hydrating caches.”

🟦 Testing & Quality in React

1. 🧪 Testing Levels in React

✅ Unit Tests

Smallest piece (function, hook, component).
Isolated from external systems.

✅ Integration Tests

Multiple components working together.
Focus on behavior (e.g., form validation).

✅ E2E (End-to-End) Tests

Full app in browser (Cypress, Playwright).
Test real user flows (login, checkout).

⚠️ Gotchas

Too many unit tests = brittle, low confidence.
E2E tests = slow, flakier, but higher confidence.
Best strategy = Testing Pyramid (more unit, fewer E2E).

🎯 Interview One-Liner

“Use a pyramid: many unit tests, fewer integration tests, and critical E2E flows. Don’t over-invest in one level.”

2. 📚 React Testing Library (RTL)

Definition:
The de-facto standard for testing React components.

✅ Key Points

Encourages testing behavior, not implementation.
Query DOM with role, text, label instead of class names.
Built on top of DOM Testing Library.

Example

render(<button>Click</button>);
fireEvent.click(screen.getByText("Click"));
expect(screen.getByRole("button")).toBeEnabled();

⚠️ Gotchas

Avoid testing internal states (wrapper.state()).
Prefer userEvent over fireEvent for realistic interactions.

🎯 Interview One-Liner

“RTL tests React by user behavior, not internals — query by role/label, simulate real events with userEvent.”

3. 🧑‍🔬 Snapshot Testing

Definition:
Tests that render component → compare output to saved snapshot.

✅ Key Points

Fast way to catch unexpected UI changes.
Great for static, predictable components (icons, design tokens).

⚠️ Gotchas

Overused snapshots → noisy diffs, brittle tests.
Not a substitute for behavior tests.

🎯 Interview One-Liner

“Snapshots are useful for static UI checks, but overusing them leads to brittle tests. Prefer behavioral assertions.”

4. 🔌 Mocking APIs

✅ Common Tools

jest.mock for modules.
fetch mocks with jest-fetch-mock.
Mock Service Worker (MSW): intercepts fetch/XHR → simulates API at network layer.

✅ MSW Example

rest.get("/user", (req, res, ctx) => {
  return res(ctx.json({ name: "Alice" }));
});

⚠️ Gotchas

Don’t mock too low-level → tests become unrealistic.
MSW > manual mocks because it simulates the network layer.

🎯 Interview One-Liner

“Mock APIs at the network layer with MSW for realistic tests. Avoid low-level mocks that make tests lie.”

5. 🎭 E2E Testing (Cypress / Playwright)

✅ Key Points

Simulate full browser environment.
Test critical flows: login, checkout, dashboard.
Integrates with CI pipelines.

✅ Differences

Cypress: simple API, auto-wait, great ecosystem.
Playwright: faster, better cross-browser & parallel support.

⚠️ Gotchas

Flaky tests from network delays → fix with retries or MSW.
Keep E2E tests minimal but critical (happy path + critical edge cases).

🎯 Interview One-Liner

“Use E2E tests for mission-critical flows. Cypress is popular, Playwright is faster and cross-browser. Keep them lean.”

6. 📊 Performance Testing

✅ Tools

React Profiler API → measure render times.
Lighthouse → web vitals (LCP, FID/INP, CLS).
WebPageTest for network analysis.

✅ Strategies

Write automated perf budgets → fail CI if LCP/CLS regress.
Use flame graphs in Profiler to find re-render storms.

🎯 Interview One-Liner

“Performance tests track user-centric metrics (LCP, INP, CLS). Use React Profiler + Lighthouse, and enforce budgets in CI.”

7. 🧩 Testing Hooks

✅ Tools

@testing-library/react-hooks (deprecated, now in @testing-library/react).

Example

function useCounter() {
  const [c, setC] = useState(0);
  return { c, inc: () => setC(c+1) };
}
const { result } = renderHook(() => useCounter());
act(() => result.current.inc());
expect(result.current.c).toBe(1);

⚠️ Gotchas

Always wrap state updates in act().
Don’t over-test hooks — test their consumer components instead.

🎯 Interview One-Liner

“Hooks can be tested directly with renderHook, but prefer testing components that consume them for realistic behavior.”

8. 🛡️ Best Practices for React Testing

Test user behavior, not implementation.
Minimize mocks → prefer integration-level tests.
Keep snapshots small and targeted.
Use MSW for realistic API mocking.
Focus E2E tests on critical flows only.
Measure performance with budgets in CI.
Maintain test pyramids → don’t drown in E2E tests.

🟦 React Ecosystem & Future

1. 🌐 Next.js Internals

Definition:
Next.js is the most popular React meta-framework, adding SSR, routing, and data-fetching.

✅ Rendering Modes

SSG (Static Site Generation): Pre-render at build time.
SSR (Server-Side Rendering): Render per request.
ISR (Incremental Static Regeneration): Re-generate stale pages on demand.
Streaming SSR (React 18): Progressive HTML streaming.

✅ Routing

Pages router (legacy).
App router (React 18 Suspense + Server Components).

⚠️ Gotchas

Mixing SSG + client hydration can cause mismatch errors.
ISR requires cache invalidation strategy.

🎯 Interview One-Liner

“Next.js supports SSG, SSR, ISR, and streaming SSR. Its App Router integrates React Server Components for hybrid server+client rendering.”

2. 🎭 Remix

Definition:
A full-stack React framework focused on web fundamentals.

✅ Key Points

Loaders & Actions: Server APIs for data & mutations.
Nested Routing: Data & layout are scoped per route.
Progressive Enhancement: Works even without JS.

⚠️ Gotchas

Tighter coupling to HTTP (good or bad depending on team).
Smaller ecosystem compared to Next.js.

🎯 Interview One-Liner

“Remix embraces the web platform: loaders/actions for data, nested routes for composition, and progressive enhancement by default.”

3. 🧩 React Server Components (RSC)

Definition:
React components that render only on the server, never shipping JS to the client.

✅ Benefits

Smaller client bundles.
Fetch data directly (no hooks needed).
Seamless integration with client components.

⚠️ Gotchas

Not yet widely supported outside Next.js App Router.
Requires strict separation between server & client components.

🎯 Interview One-Liner

“React Server Components render only on the server, reducing client JS. They fetch data directly and stream into client trees.”

4. ⚡ React Compiler (Future)

Definition:
Meta’s upcoming optimization tool that auto-memoizes components.

✅ Key Points

Removes manual need for useMemo/useCallback.
Already in production at Meta (as of 2024–25).
Analyzes dependency usage at build-time.

🎯 Interview One-Liner

“React Compiler auto-memoizes components, eliminating most manual useMemo/useCallback. It’s already in use at Meta.”

5. 📱 React Native

✅ Key Points

Same React API, renders to native views (iOS/Android).
Uses a bridge (JS ↔ native).
New architecture: JSI + Fabric renderer + TurboModules → faster, less overhead.

⚠️ Gotchas

Not true “write once, run anywhere” → platform-specific tuning still needed.
Performance depends on new architecture adoption.

🎯 Interview One-Liner

“React Native shares React’s model but renders native components. Its new architecture (Fabric/JSI) reduces bridge overhead.”

6. 🧪 Alternative Frameworks

✅ Preact

Lightweight React alternative (~3KB).
Same API, drop-in for React (with aliasing).
Used in performance-critical apps.

✅ Solid.js

Fine-grained reactivity (signals instead of VDOM).
Much faster for many scenarios.

✅ Qwik

Resumability: ships zero JS initially, resumes state on demand.
Solves hydration overhead in huge apps.

🎯 Interview One-Liner

“Alternatives like Preact (lightweight React), Solid (fine-grained reactivity), and Qwik (resumable apps) push forward new performance models.”

7. 🔄 Migration Strategies

✅ Class → Hooks

Incrementally refactor components.
Wrap legacy lifecycles in custom hooks.

✅ Legacy React → Modern (Concurrent + Suspense)

Use StrictMode to surface unsafe lifecycles.
Refactor componentWillMount/componentWillReceiveProps.
Replace legacy Context API with new API.

✅ Monolith → Micro-Frontends

Strangle pattern: carve out routes/modules.
Share design system first.

🎯 Interview One-Liner

“Migrations must be incremental: class → hooks, legacy → concurrent features, monolith → micro-frontends via strangle pattern.”

8. 🔮 Future of React

✅ Trends

React Server Components → data + rendering shift server-side.
Streaming SSR → better TTFB.
React Compiler → auto-memoization.
Signals (inspired by Solid.js) → may influence React state model.
Concurrent UI as default → more user-perceived responsiveness.

🎯 Interview One-Liner

“React’s future focuses on server components, streaming SSR, auto-memoization via React Compiler, and adopting ideas from signals-based reactivity.”

✅ Summary (Full Handbook)

This React handbook covers staff/architect-level depth:

React Core Fundamentals (VDOM, reconciliation, Fiber, phases, lifecycle, hooks rules, context, controlled/uncontrolled inputs)
State Management (useState vs useReducer, local vs global, Context, Redux/RTK, Zustand/Recoil/Jotai, snapshot vs event-driven, normalization, immutability)
Performance & Optimization (re-renders, memoization, batching, concurrent rendering, transitions, virtualization, Suspense, profiling)
Advanced Hooks & Patterns (custom hooks, HOCs vs render props, compound components, controlled/uncontrolled, prop getters, refs & imperative APIs, useEffect vs useLayoutEffect, error boundaries)
Concurrent Features & Architecture (Fiber, lanes, render vs commit, concurrent rendering, transitions, Suspense, streaming SSR, RSC, hydration, React Compiler)
React and the Browser (synthetic events, portals, concurrent input handling, CSS strategies, accessibility, browser observers, rendering pipeline)
Large-Scale Architecture (CDD, theming, monorepos, micro-frontends, error boundaries, observability, security, scalability best practices)
React with Data (fetching, caching, Suspense, optimistic UI, streaming, race conditions, error handling, prefetching & dehydration)
Testing & Quality (pyramid, RTL, snapshots, MSW, Cypress/Playwright, performance testing, hooks testing, best practices)
Ecosystem & Future (Next.js, Remix, RSC, Compiler, React Native, alternatives like Preact/Solid/Qwik, migration strategies, future trends)

Core JavaScript Expert Revision Handbook

Animesh Pandey — Sun, 31 Aug 2025 18:50:43 +0000

📑 Table of Contents

Closures, Scope, Hoisting, this, Prototypes, Event Loop
Asynchronous JavaScript
Advanced Objects & Memory
Advanced Functions & ES6+ Features
Browser & DOM Fundamentals
Performance & Optimization
Advanced Types & Equality
Error Handling & Debugging
Concurrency & Parallelism
ESNext & Modern Features
Patterns & Architecture in JavaScript

🟦 Part 1

This section covers Closures, Scope & Hoisting, this, Prototypes, and the Event Loop — the foundation of almost every frontend interview.

1. 🔒 Closures

Definition:
A closure is a function that retains access to its lexical environment (scope chain) even after the outer function has finished executing.

✅ Key Points

JavaScript uses lexical scoping, not dynamic scoping.
Closures are formed naturally whenever a function is defined inside another.
Enable data privacy, currying, memoization, event handlers.

⚠️ Gotchas

Loop with var:

  for (var i = 0; i < 3; i++) {
    setTimeout(() => console.log(i), 100);
  }
  // 3, 3, 3 (same var captured)

Fix with let (block-scoped) or IIFE.

Memory leaks:
Closures capturing large objects (like DOM nodes) can prevent garbage collection.
Debugging pain:
DevTools may show “unexpected” retained variables due to closures.

💡 Real-world Bug

function registerHandlers(nodes) {
  for (var i = 0; i < nodes.length; i++) {
    nodes[i].onclick = () => console.log("Clicked:", i);
  }
}
// All handlers print last index!

🎯 Interview One-Liner

“A closure is a function with its lexical scope bundled in. It enables encapsulation and callbacks but can cause bugs with loops (var) and memory leaks if you capture more than needed.”

2. 📦 Scope & Hoisting

Definition:
Scope defines where variables are accessible. Hoisting means declarations are moved to the top of their scope during compilation.

✅ Key Points

var → function-scoped, hoisted & initialized as undefined.
let/const → block-scoped, hoisted but uninitialized (Temporal Dead Zone, TDZ).
Function declarations → fully hoisted with body.
Function expressions → behave like variables.

⚠️ Gotchas

TDZ Example:

  console.log(x); // ReferenceError
  let x = 10;

Function in block scope:

  if (true) {
    function foo() {}
  }
  foo(); // Works differently in strict vs sloppy mode

Shadowing:

  let x = 1;
  {
    let x = 2;
    console.log(x); // 2 (outer x hidden)
  }

🔄 Quick Table

Keyword	Scope	Hoisting	Default Init
`var`	Function	Yes	`undefined`
`let`	Block	Yes	TDZ (error)
`const`	Block	Yes	TDZ (error)
Function	Function	Yes (with body)	-

🎯 Interview One-Liner

“Declarations are hoisted. var hoists with undefined; let/const hoist into the TDZ; functions hoist with their body. That’s why accessing a let before declaration throws, while var gives undefined.”

3. 🧭 The `this` Keyword

Definition:
this is determined by the call site, not the definition.

✅ Rules of `this` Binding (Precedence)

new binding → new Foo()
explicit binding → call, apply, bind
implicit binding → obj.method()
default binding → global (window) or undefined (strict mode)

⚠️ Gotchas

Losing context:

  const obj = { x: 10, f() { console.log(this.x); } };
  setTimeout(obj.f, 0); // undefined (lost `this`)

Arrow functions: capture lexical this, cannot be rebound.
bind + call combo:

  function f() { console.log(this.x); }
  const bound = f.bind({ x: 1 });
  bound.call({ x: 2 }); // still 1 (bind wins)

🔄 Quick Table

Call Type	`this` Value
Global fn (non-strict)	`window`
Global fn (strict)	`undefined`
Method call `obj.fn()`	`obj`
`new Fn()`	New instance
Bound fn	Bound object
Arrow fn	Lexical scope

🎯 Interview One-Liner

“this is set at call time, not definition. Precedence is: new > explicit (bind) > implicit (object call) > default (global/undefined). Arrow functions inherit this lexically.”

4. 🧩 Prototypes & Inheritance

Definition:
Objects inherit properties via the prototype chain ([[Prototype]]).

✅ Key Points

Object.create(proto) → creates object with proto as prototype.
Functions have a .prototype used when called with new.
Property lookup climbs prototype chain.

⚠️ Gotchas

Modifying .prototype after instances exist → they won’t see changes.
Shadowing: own property hides prototype property.
Deep prototype chains slow lookups.

Code Example

function Animal(name) { this.name = name; }
Animal.prototype.speak = function() { console.log(this.name + " makes noise"); }

const dog = new Animal("Rex");
dog.speak(); // "Rex makes noise"

console.log(dog.__proto__ === Animal.prototype); // true

🎯 Interview One-Liner

“Objects inherit via prototypes. If a property isn’t found, JS looks up the chain. Constructors set their .prototype as the prototype of new instances.”

5. ⏳ Event Loop & Concurrency

Definition:
The event loop coordinates execution: it runs the call stack, then processes the task queues (macrotasks and microtasks).

✅ Key Points

Macrotasks: setTimeout, setInterval, I/O.
Microtasks: Promises, MutationObserver, queueMicrotask.
After each macrotask, the loop drains all microtasks.

⚠️ Gotchas

setTimeout(fn, 0) is not immediate — runs after microtasks.
Promise.then always executes before timeouts.
In Node.js, process.nextTick runs before microtasks.
Nested promises keep chaining microtasks → possible starvation.

Code Example

console.log("A");

setTimeout(() => console.log("B"), 0);

Promise.resolve().then(() => console.log("C"));

console.log("D");

// Output: A, D, C, B

🔄 Execution Order

Run call stack
Drain microtask queue
Run next macrotask
Repeat

🎯 Interview One-Liner

“The event loop runs stack → microtasks → macrotasks. That’s why Promise.then callbacks run before setTimeout(fn, 0).”

🟦 Asynchronous JavaScript

1. ⏱️ Timers (`setTimeout`, `setInterval`)

Definition:
setTimeout(fn, delay) schedules a function once after delay; setInterval(fn, delay) repeats at intervals.

✅ Key Points

Actual delay is minimum — not guaranteed exact.
Nested timers can be throttled by browsers (clamp to ≥4ms after many calls, 1000ms when tab inactive).
clearTimeout / clearInterval cancel scheduled tasks.

⚠️ Gotchas

setTimeout(fn, 0) runs after all microtasks (not immediate).
Long-running tasks block timers (since JS is single-threaded).
setInterval can drift → better to use recursive setTimeout for accuracy.

Example

setTimeout(() => console.log("timeout"), 0);
Promise.resolve().then(() => console.log("promise"));
// Output: promise, timeout

🎯 Interview One-Liner

“Timers schedule macrotasks. setTimeout(fn, 0) isn’t immediate — it runs after microtasks. For precise intervals, recursive setTimeout is safer than setInterval.”

2. 🔗 Promises

Definition:
A Promise is an object representing the eventual result of an async operation.

✅ Key Points

States: pending → fulfilled (resolved) / rejected.
.then and .catch return new promises → enable chaining.
Handlers are always async (enqueued as microtasks).

⚠️ Gotchas

Unhandled rejection:

  Promise.reject("err");
  // Without .catch → unhandled rejection warning

.then handlers always async:

  Promise.resolve().then(() => console.log("then"));
  console.log("sync");
  // sync, then

Multiple .then on the same promise all execute independently.
Returning a promise inside .then flattens it (automatic chaining).

Example

Promise.resolve(1)
  .then(x => x + 1)
  .then(x => Promise.resolve(x + 1))
  .then(console.log); // 3

🎯 Interview One-Liner

“Promises represent async results. .then handlers are always microtasks, so they run before timers. Returning a promise in .then flattens the chain.”

3. ⚡ `async` / `await`

Definition:
Syntactic sugar over promises. async functions return promises; await pauses until promise settles.

✅ Key Points

await only works inside async functions (or top-level in modules).
Execution is split → code after await runs in a microtask.
Parallelize with Promise.all to avoid serial awaits.

⚠️ Gotchas

await inside loops → serial execution (slow).

  for (const u of users) {
    await fetch(u); // slow
  }
  await Promise.all(users.map(u => fetch(u))); // fast

try/catch is needed — await throws on rejection.
Mixing await with non-promises just wraps in Promise.resolve.

Example

async function f() {
  console.log("A");
  await Promise.resolve();
  console.log("B");
}
f();
console.log("C");

// Output: A, C, B

🎯 Interview One-Liner

“async/await is syntax sugar over promises. await pauses execution and resumes in a microtask. Using it inside loops serializes calls — use Promise.all for parallelism.”

4. 🎛️ Generators & Async Generators

Definition:
Generators (function*) are functions that can pause and resume using yield. Async generators use for await...of.

✅ Key Points

Generators return an iterator with .next().
Useful for building custom async workflows (before promises).
co library + generators → pre-async/await async management.

⚠️ Gotchas

Generators don’t manage async by themselves; must yield promises and have a runner.
Async generators (async function*) combine promises with iteration.

Example

function* gen() {
  yield 1;
  yield 2;
}
const g = gen();
console.log(g.next()); // { value: 1, done: false }

🎯 Interview One-Liner

“Generators pause with yield and resume later. They’re useful for async flow control, but in modern JS, async/await replaces most generator use cases.”

5. ⏳ Debounce & Throttle

Definition:
Patterns for rate-limiting function execution.

Debounce: wait until no calls happen for X ms. (Good for search input).
Throttle: allow one call per X ms. (Good for scroll/resize).

Example

function debounce(fn, delay) {
  let timer;
  return (...args) => {
    clearTimeout(timer);
    timer = setTimeout(() => fn(...args), delay);
  };
}

function throttle(fn, delay) {
  let last = 0;
  return (...args) => {
    const now = Date.now();
    if (now - last >= delay) {
      fn(...args);
      last = now;
    }
  };
}

🎯 Interview One-Liner

“Debounce delays execution until events stop; throttle limits execution to once per interval. Debounce is for inputs, throttle for continuous events like scroll.”

6. 🎨 requestAnimationFrame (rAF)

Definition:
requestAnimationFrame(callback) schedules a callback before the next repaint (~16.6ms at 60fps).

✅ Key Points

More efficient than setTimeout for animations.
Pauses when tab is inactive (better for performance).
Ideal for smooth visual updates.

⚠️ Gotchas

Doesn’t guarantee 60fps — depends on device refresh rate.
Can be canceled with cancelAnimationFrame(id).

Example

function animate() {
  // draw frame
  requestAnimationFrame(animate);
}
animate();

🎯 Interview One-Liner

“requestAnimationFrame runs a callback before the next repaint. It’s optimized for animations and pauses in inactive tabs.”

7. 🧵 Web Workers

Definition:
Web Workers run JS in background threads, off the main event loop.

✅ Key Points

Communicate via postMessage (structured clone).
No DOM access inside workers.
Good for CPU-heavy tasks.

⚠️ Gotchas

Serialization overhead in postMessage.
SharedArrayBuffer needed for true shared memory.
Not supported in all contexts (e.g., some cross-origin iframes).

Example

// worker.js
self.onmessage = e => {
  self.postMessage(e.data * 2);
};

// main.js
const worker = new Worker("worker.js");
worker.onmessage = e => console.log("Result:", e.data);
worker.postMessage(10); // Result: 20

🎯 Interview One-Liner

“Web Workers move heavy computation off the main thread. They communicate via messages, but can’t access the DOM.”

🟦 Advanced Objects & Memory

1. 🧹 Garbage Collection (GC)

Definition:
JavaScript uses automatic garbage collection — freeing memory for objects that are no longer reachable.

✅ Key Points

Reachability = if an object can be accessed via a reference chain from a root (e.g. window or stack).
Common GC strategy: Mark & Sweep.
Circular references are fine if unreachable from root.

⚠️ Gotchas

Accidental leaks:
- Global variables (window.leak = obj).
- Closures holding large structures.
- Detached DOM nodes retained in memory.
Timers / event listeners: If not cleared, they keep references alive.

Example

let el = document.getElementById("btn");
el.onclick = () => console.log("clicked");
// If `el` removed from DOM but reference stays in closure → leak

🎯 Interview One-Liner

“GC frees unreachable memory. Leaks usually happen via globals, closures, or dangling DOM references, not because of circular references.”

2. 🗝️ Symbols

Definition:
Symbol() creates a unique primitive identifier.

✅ Key Points

Never equal to another symbol, even with same description.
Used for non-colliding property keys.
Symbol.for(key) reuses a global registry symbol.
Built-in symbols customize behavior (Symbol.iterator, Symbol.toStringTag).

⚠️ Gotchas

for...in and Object.keys ignore symbols. Must use Object.getOwnPropertySymbols.
JSON.stringify ignores symbols.

Example

const id = Symbol("id");
const obj = { [id]: 123 };
console.log(Object.keys(obj)); // []
console.log(Object.getOwnPropertySymbols(obj)); // [Symbol(id)]

🎯 Interview One-Liner

“Symbols are unique identifiers, often used as hidden object keys or to customize built-in behaviors. They’re ignored by JSON and normal enumeration.”

3. 🗄️ WeakMap & WeakSet

Definition:
Weak collections hold weak references to objects — allowing GC when there are no other references.

✅ Key Points

WeakMap: keys must be objects, values arbitrary.
WeakSet: stores objects, prevents duplicates.
Entries are not enumerable (no size, no iteration).

⚠️ Gotchas

Can’t inspect contents → intentionally opaque.
Useful for private data or DOM element caching.

Example

let wm = new WeakMap();
let obj = {};
wm.set(obj, "secret");

console.log(wm.get(obj)); // "secret"
obj = null; // entry auto-removed when GC runs

🎯 Interview One-Liner

“WeakMap/WeakSet hold weak references — objects can be GC’d even if they’re keys. They’re ideal for caching and private data without leaks.”

4. 📝 Property Descriptors

Definition:
Every property has a descriptor object with attributes:

value
writable
enumerable
configurable (or get/set for accessors).

✅ Key Points

Object.defineProperty controls property behavior.
enumerable controls visibility in loops.
configurable prevents deletion or redefinition.
Non-writable prevents assignment.

⚠️ Gotchas

Default attributes: false if defined via defineProperty.
Freezing (Object.freeze) sets all writable=false, configurable=false.

Example

const obj = {};
Object.defineProperty(obj, "x", {
  value: 42,
  writable: false,
  enumerable: true,
  configurable: false
});
obj.x = 100; // ignored in strict mode → TypeError

🎯 Interview One-Liner

“Property descriptors let you control attributes like writable, enumerable, configurable. They’re the foundation of Object.freeze and getters/setters.”

5. 🕵️ Proxy & Reflect

Definition:
Proxy allows you to intercept operations on objects. Reflect provides low-level methods that mirror default behavior.

✅ Key Points

Handlers (traps): get, set, has, deleteProperty, apply, construct.
Reflect ensures correct forwarding (avoids reinventing default behavior).
Used for logging, validation, virtualization, reactive systems (Vue3 uses Proxy).

⚠️ Gotchas

Proxies can slow performance if overused.
Can break identity expectations (obj === proxy is false).
Some operations (like private fields) are not trap-able.

Example

const obj = { a: 1 };
const proxy = new Proxy(obj, {
  get(target, prop) {
    console.log("get", prop);
    return target[prop];
  }
});

console.log(proxy.a); // logs: get a → 1

🎯 Interview One-Liner

“Proxies wrap objects with traps for operations like get/set. Reflect provides the default behavior to forward calls. Proxies power modern reactivity systems.”

6. 🧊 Immutability Tricks

Definition:
JavaScript objects are mutable by default. Immutability ensures predictable state (important in React/Redux).

✅ Key Points

Object.freeze → prevents modifications.
Object.seal → prevents adding/removing props, but can update values.
Object.preventExtensions → prevents new props, but allows edits/deletes.
Deep immutability requires recursion or libraries (immer).

⚠️ Gotchas

Freeze is shallow — nested objects still mutable.
Frozen objects are still extensible by changing prototype unless explicitly blocked.

Example

const obj = Object.freeze({ x: 1, y: { z: 2 } });
obj.x = 10; // ignored
obj.y.z = 20; // allowed (nested not frozen)

🎯 Interview One-Liner

“Objects are mutable by default. freeze/seal/preventExtensions restrict changes, but only shallowly. For deep immutability, you need recursion or libraries like Immer.”

🟦 Advanced Functions & ES6+ Features

1. 🏗️ Higher-Order Functions (HOFs)

Definition:
Functions that either take functions as arguments or return functions.

✅ Key Points

Foundation of functional programming.
Enable: map, filter, reduce, decorators, middleware.
Encourage immutability + composition.

⚠️ Gotchas

Passing non-functions → runtime errors.
Excessive nesting → callback hell (before Promises/async).

Example

function withLogging(fn) {
  return (...args) => {
    console.log("Calling with", args);
    return fn(...args);
  };
}
const sum = (a, b) => a + b;
const loggedSum = withLogging(sum);
loggedSum(2, 3); // logs args → 5

🎯 Interview One-Liner

“A higher-order function either takes functions as arguments or returns them. They enable abstractions like map, filter, and middleware.”

2. 🎨 Currying & Partial Application

Definition:

Currying: Transforming a function f(a, b, c) into f(a)(b)(c).
Partial application: Pre-filling some arguments, returning a new function.

✅ Key Points

Used in FP libraries like Lodash, Ramda.
Helps reusability and function composition.

⚠️ Gotchas

Over-currying → unreadable code.
Currying ≠ partial application (though related).

Example

const currySum = a => b => c => a + b + c;
currySum(1)(2)(3); // 6

function partial(fn, ...fixed) {
  return (...rest) => fn(...fixed, ...rest);
}
const add = (a, b) => a + b;
const add5 = partial(add, 5);
add5(10); // 15

🎯 Interview One-Liner

“Currying breaks a function into unary steps (f(a)(b)(c)), while partial application pre-fills arguments. Both improve reusability.”

3. 📦 Modules (ESM vs CommonJS)

Definition:
Modules encapsulate code into reusable files.

✅ Key Points

CommonJS (CJS): Node.js legacy (require, module.exports).
ES Modules (ESM): Modern JS (import, export).
ESM is statically analyzable → enables tree-shaking.
Default exports vs named exports.

⚠️ Gotchas

Mixing CJS and ESM leads to quirks (default interop).
ESM is always strict mode.
Imports are hoisted (run before any other code).

Example

// utils.js
export function add(a, b) { return a + b; }
export default function subtract(a, b) { return a - b; }

// main.js
import subtract, { add } from "./utils.js";

🎯 Interview One-Liner

“CommonJS uses require, ES Modules use import/export. ESM is statically analyzable and supports tree-shaking, which is why modern bundlers prefer it.”

4. ✨ Destructuring & Spread/Rest

Definition:
Syntax for unpacking values into variables.

✅ Key Points

Array destructuring: [a, b] = arr.
Object destructuring: { x, y } = obj.
Rest: gather leftovers.
Spread: expand arrays/objects.

⚠️ Gotchas

Nested destructuring → undefined if property missing.
Default values only apply when property is undefined, not null.

Example

const [a, b = 5] = [1];
console.log(a, b); // 1, 5

const { x, y: z } = { x: 10, y: 20 };
console.log(z); // 20

const arr = [1, 2];
const newArr = [...arr, 3]; // [1,2,3]

🎯 Interview One-Liner

“Destructuring unpacks arrays/objects, rest gathers leftovers, spread expands. Defaults only trigger on undefined, not null.”

5. 🧾 Default, Rest, and Named Parameters

✅ Key Points

Default params:

  function f(x = 10) { return x; }
  f(); // 10

Rest params: collects extra args → array.
Named params: simulated with object destructuring.

⚠️ Gotchas

Default params are evaluated at call time.
Rest params differ from arguments (rest is real array, arguments is array-like).

🎯 Interview One-Liner

“Default params evaluate at call time, rest params gather extras as a real array, and named params are simulated via object destructuring.”

6. 🔄 Iterators & Iterables

Definition:
An iterator is an object with .next(). An iterable has [Symbol.iterator].

✅ Key Points

Iterables: arrays, strings, maps, sets.
for...of loops over iterables (not plain objects).
Custom iterables by implementing [Symbol.iterator].

⚠️ Gotchas

Plain objects aren’t iterable unless you define [Symbol.iterator].
Spread ...obj works only if iterable defined.

Example

const iterable = {
  *[Symbol.iterator]() {
    yield 1; yield 2; yield 3;
  }
};
for (const x of iterable) console.log(x);

🎯 Interview One-Liner

“Iterables implement [Symbol.iterator], which returns an iterator with .next(). That’s why arrays, maps, and sets work with for...of and spread.”

7. 📚 Map, Set, WeakMap, WeakSet

Definition:
Specialized collection types introduced in ES6.

✅ Key Points

Map: key-value pairs, keys can be any type.
Set: unique values.
WeakMap/WeakSet: only object keys, weak references (non-enumerable).

⚠️ Gotchas

NaN is considered equal to itself in Set.
Map preserves insertion order.
WeakMap doesn’t prevent GC.

Example

const set = new Set([1, 2, 2, 3]);
console.log(set.size); // 3

const map = new Map();
map.set("a", 1).set({}, 2);

🎯 Interview One-Liner

“Map and Set are collections with insertion order preserved. WeakMap/WeakSet hold weak object references, useful for caching without memory leaks.”

8. 🧭 ES6+ Extras (that interviewers test)

🔑 Template Literals

const name = "Alex";
console.log(`Hello ${name}`);

🔑 Tagged Templates

function tag(strings, ...values) {
  return strings[0] + values.map(v => v.toUpperCase()).join("");
}
console.log(tag`Hi ${"alex"} and ${"bob"}`); // "Hi ALEXandBOB"

🔑 Optional Chaining & Nullish Coalescing

obj?.prop?.nested; // avoids TypeError
val ?? "default";  // only default if null/undefined

🎯 Interview One-Liner

“Modern JS adds quality-of-life features like template literals, optional chaining (?.), and nullish coalescing (??). These avoid common boilerplate and bugs.”

🟦 Browser & DOM Fundamentals

1. 🎯 Event Delegation

Definition:
Attaching a single event listener on a parent to handle events for multiple child elements via event bubbling.

✅ Key Points

Uses event propagation (capture → target → bubble).
Reduces memory usage (no per-child listeners).
Works well for dynamic DOM (children added later).

⚠️ Gotchas

event.target vs event.currentTarget:
- target = actual clicked element.
- currentTarget = element with listener.
Some events don’t bubble (e.g., blur, focus).

Example

document.getElementById("list").addEventListener("click", e => {
  if (e.target.tagName === "LI") {
    console.log("Clicked item:", e.target.textContent);
  }
});

🎯 Interview One-Liner

“Event delegation attaches a single listener on a parent and relies on bubbling. It’s efficient for many/dynamic child elements.”

2. 🖼️ Reflow vs Repaint (Performance)

Definition:

Reflow (layout): Browser recalculates element positions & sizes.
Repaint: Browser redraws pixels (e.g., color change).

✅ Key Points

Reflow is more expensive than repaint.
Causes of reflow: DOM changes, style changes, window resize, font load.
Batch DOM reads/writes to avoid multiple reflows.

⚠️ Gotchas

Accessing layout properties (offsetHeight, scrollTop) forces reflow.
Animating top/left triggers layout; animating transform/opacity is GPU-optimized.

Example

const el = document.getElementById("box");
el.style.width = "200px";          // triggers reflow
console.log(el.offsetHeight);      // forces reflow again (expensive)

🎯 Interview One-Liner

“Reflow recalculates layout, repaint redraws pixels. Reflow is costly — optimize by batching DOM changes and animating transform/opacity.”

3. 🌳 DOM Traversal & Manipulation

✅ Methods

getElementById, querySelector, querySelectorAll.
parentNode, children, nextSibling.
Creating: document.createElement, appendChild, insertBefore.
Performance: Use DocumentFragment for batch insertions.

⚠️ Gotchas

innerHTML is faster for large inserts but unsafe (XSS risk).
NodeList vs HTMLCollection:
- NodeList can be static or live.
- HTMLCollection is always live.

🎯 Interview One-Liner

“DOM traversal uses APIs like querySelector, parentNode, and siblings. For performance, batch inserts with DocumentFragment instead of repeated appendChild.”

4. 💾 Storage APIs

✅ Key Points

Cookies:
- 4KB limit.
- Sent with every HTTP request.
- Expiration & domain/path scoped.
localStorage:
- 5–10MB.
- Synchronous API.
- Persistent until cleared.
sessionStorage:
- Per-tab/session.
IndexedDB:
- Async, NoSQL DB in browser.
- Large storage, structured queries.

⚠️ Gotchas

localStorage is blocking → avoid heavy writes in main thread.
Cookies hurt performance since they’re sent on every request.
IndexedDB APIs are clunky (usually use wrapper libraries).

🎯 Interview One-Liner

“Cookies are for server comms (small, auto-sent), localStorage/sessionStorage for small client-only data, and IndexedDB for large structured storage.”

5. 🔒 Browser Security (CORS, CSRF, XSS)

✅ CORS (Cross-Origin Resource Sharing)

Controls cross-domain requests.
Server sets Access-Control-Allow-Origin.

✅ CSRF (Cross-Site Request Forgery)

Malicious site tricks user’s browser into sending authenticated request.
Prevented with CSRF tokens or SameSite cookies.

✅ XSS (Cross-Site Scripting)

Injected scripts executed in victim’s browser.
Prevented with escaping, CSP (Content Security Policy).

🎯 Interview One-Liner

“CORS controls which origins can access resources, CSRF tricks users into sending unwanted requests, and XSS injects malicious scripts. Fix with headers, tokens, and sanitization.”

6. ⚡ Service Workers

Definition:
Background scripts that intercept network requests → enable offline caching, push notifications, background sync.

✅ Key Points

Use Cache API for offline storage.
Run in their own thread (no DOM access).
Lifecycle: install → activate → fetch.

⚠️ Gotchas

Require HTTPS.
Debugging can be tricky (stale workers → need manual refresh).
Misuse can cause cache-bloat or stale responses.

Example

self.addEventListener("fetch", e => {
  e.respondWith(
    caches.match(e.request).then(res => res || fetch(e.request))
  );
});

🎯 Interview One-Liner

“Service workers are background scripts that enable offline caching and network interception. They power PWAs but must be carefully managed to avoid stale caches.”

7. 🌐 Critical Rendering Path (CRP)

Definition:
Steps the browser takes to convert HTML/CSS/JS into pixels.

✅ Stages

Parse HTML → DOM
Parse CSS → CSSOM
Combine → Render Tree
Layout (Reflow)
Paint (Repaint)
Composite layers

⚠️ Gotchas

Render-blocking: CSS blocks rendering, JS blocks parsing unless defer/async.
Fonts: FOUT/FOIT issues (Flash of Unstyled/Invisible Text).

🎯 Interview One-Liner

“The CRP is DOM + CSSOM → render tree → layout → paint → composite. Optimize by deferring scripts, minimizing CSS, and preloading fonts.”

8. 🧩 Resource Loading (`async` vs `defer`)

Definition:
Attributes that control how scripts load.

✅ Key Points

async: downloads in parallel, executes ASAP (order not guaranteed).
defer: downloads in parallel, executes after HTML parse, preserves order.
Default: blocking (bad for performance).

🎯 Interview One-Liner

“Use defer for scripts that rely on DOM, async for independent scripts. Default blocking scripts delay parsing and hurt performance.”

🟦 Core JavaScript — Expert-Level Revision

🟦 Performance & Optimization

1. 🧹 Memory Leaks in Frontend

Definition:
A memory leak happens when memory is not released after it’s no longer needed.

✅ Common Sources

Uncleared timers/intervals:

  setInterval(() => { /* ... */ }, 1000); // never cleared

Detached DOM nodes kept in closures or global arrays.
Event listeners not removed on unmount.
Global variables and singletons that grow unbounded.

🎯 Interview One-Liner

“Frontend leaks often come from forgotten event listeners, timers, or DOM nodes retained in closures. Use cleanup (clearInterval, removeEventListener) and profiling tools.”

2. 💤 Lazy Loading & Code Splitting

Definition:
Splitting bundles into smaller chunks and loading them on demand.

✅ Key Points

Reduces initial load time.
Implemented with dynamic imports (import()), route-based splitting.
Use React.lazy + Suspense for components.

⚠️ Gotchas

Too many small chunks → overhead.
Network latency can hurt if misconfigured.

🎯 Interview One-Liner

“Lazy loading reduces initial load by splitting code into chunks. Use import() or React.lazy. Balance chunk size to avoid too many round-trips.”

3. 🌳 Tree-Shaking

Definition:
Removing unused code during bundling.

✅ Key Points

Works only with ESM (import/export) because it’s statically analyzable.
Dead code elimination depends on bundler + minifier (Webpack, Rollup, Terser).

⚠️ Gotchas

Dynamic require() prevents tree-shaking.
Side-effects in modules can block elimination.

🎯 Interview One-Liner

“Tree-shaking eliminates unused exports but only works with static ES modules. Avoid dynamic imports and side-effects in libraries.”

4. ⚡ Web Vitals

Definition:
Google’s metrics for user-perceived performance.

✅ Core Metrics

LCP (Largest Contentful Paint): load speed (<2.5s).
FID (First Input Delay): input responsiveness (<100ms).
CLS (Cumulative Layout Shift): visual stability (<0.1).
(New) INP (Interaction to Next Paint) replacing FID.

🎯 Interview One-Liner

“Web Vitals measure perceived performance: LCP for load, FID/INP for input, CLS for stability. Optimize via lazy loading, preloading, and reducing JS.”

5. 🧾 Async Scheduling (Idle Time)

Definition:
Scheduling work when the browser is idle.

✅ Key Points

requestIdleCallback(cb) → runs when browser is idle.
Useful for non-critical background work.
Fallback to timers for unsupported browsers.

⚠️ Gotchas

Not guaranteed to run (if browser never idle).
Time budget limited (~50ms).

🎯 Interview One-Liner

“requestIdleCallback lets you run background work without blocking the main thread, but it may not fire on busy pages.”

6. 🎯 Preload, Prefetch, DNS Prefetch

✅ Key Points

Preload: critical resources needed soon.
Prefetch: resources likely needed in future navigation.
DNS-prefetch: resolve domain names early.

Example

<link rel="preload" href="hero.jpg" as="image" />
<link rel="prefetch" href="/next-page.js" />
<link rel="dns-prefetch" href="//cdn.example.com" />

🎯 Interview One-Liner

“Preload fetches critical resources now, prefetch loads likely future ones, DNS-prefetch resolves domains early.”

7. 📦 Bundling Strategies

Monolithic bundle → fast for small apps, bad for scale.
Code-splitting → route-level chunks.
Micro-frontends → separate bundles per domain (federation).
CDN caching → cache chunks by content hash.

🎯 Interview One-Liner

“Bundle strategy depends on scale. Use route-based code splitting, cache chunks with hashes, and avoid giant monolithic bundles.”

8. 🏎️ Rendering Performance Tips

Minimize reflows (batch DOM changes).
Use transform/opacity for animations.
Virtualize large lists (e.g., react-window).
Debounce resize/scroll listeners.

🎯 Interview One-Liner

“Reflows are expensive — batch DOM updates, use transform/opacity for animations, and virtualize long lists.”

🟦 Core JavaScript — Expert-Level Revision

🟦 Advanced Types & Equality

1. 📌 Truthy & Falsy Values

Definition:
When converted to a boolean (e.g., in if conditions), some values are considered truthy or falsy.

✅ Falsy Values (only 7!)

false
0, -0
"" (empty string)
null
undefined
NaN

Everything else → truthy (including "0", [], {}, Infinity).

⚠️ Gotchas

if ("0") console.log("runs");   // runs (string "0" is truthy)
if ([]) console.log("runs");    // runs (empty array is truthy)
if ({}) console.log("runs");    // runs (empty object is truthy)

🎯 Interview One-Liner

“Only 7 values are falsy: false, 0, -0, "", null, undefined, NaN. Everything else is truthy — even empty arrays/objects.”

2. 🔄 `==` vs `===`

Definition:

=== (strict equality): no type coercion.
== (loose equality): allows coercion.

✅ Rules (selected weird ones)

0 == false        // true
"" == false       // true
null == undefined // true
[] == false       // true ( [] → "" → 0 )
[] == ![]         // true ( [] == false )
[1] == 1          // true ([1].toString() → "1")
[1,2] == "1,2"    // true

⚠️ Gotchas

NaN == NaN → false (NaN is never equal to itself).
null only equals undefined (and itself).
0 == [] is true, but 0 == {} is false.

🎯 Interview One-Liner

“=== checks value + type, no coercion. == coerces and has weird rules: null == undefined only, arrays convert to strings, and NaN never equals itself.”

3. 🧾 Special Numbers: `NaN`, `Infinity`, `-0`

✅ NaN

Not equal to itself: NaN === NaN → false.
Use Number.isNaN() (better than isNaN).
isNaN("foo") → true (coerces to NaN).

✅ Infinity

1 / 0 → Infinity.
-1 / 0 → -Infinity.

✅ -0

JS has two zeros: 0 and -0.
0 === -0 → true.
But 1 / 0 === Infinity, 1 / -0 === -Infinity.

🎯 Interview One-Liner

“JS has two zeros: +0 and -0. They compare equal with ===, but divide by them to get ±Infinity. NaN is never equal to itself.”

4. 🗝️ `Object.is`

Definition:
Like === but fixes edge cases:

✅ Rules

Object.is(NaN, NaN);   // true
Object.is(0, -0);      // false
Object.is(5, 5);       // true
Object.is({}, {});     // false (different refs)

🎯 Interview One-Liner

“Object.is is like strict equality but distinguishes -0 and +0, and treats NaN as equal to itself.”

5. 📦 Primitive vs Object Wrappers

Definition:
Primitives (string, number, boolean, symbol, bigint, null, undefined) have object wrappers for method access.

✅ Examples

"hello".toUpperCase();   // works because JS boxes into String object
new String("hello");     // object wrapper
typeof "hello";          // "string"
typeof new String("hi"); // "object"

⚠️ Gotchas

new Boolean(false) is truthy (object is always truthy).
Comparing primitive vs object:

"hi" === new String("hi"); // false
"hi" == new String("hi");  // true (coerces)

🎯 Interview One-Liner

“Primitives auto-box into wrappers (e.g., 'hi'.toUpperCase()). But wrapper objects (new String) are truthy and behave differently — avoid them.”

6. 🧩 Typeof, instanceof, and `Array.isArray`

✅ typeof

typeof null → "object" (bug since JS 1.0).
typeof NaN → "number".
typeof function() {} → "function".

✅ instanceof

Checks prototype chain.
Works across inheritance.
Fails across iframes (different globals).

✅ Array.isArray

Safest way to check arrays (cross-realm safe).

Example

[] instanceof Array;           // true
[] instanceof Object;          // true
Array.isArray([]);             // true
typeof null;                   // "object"

🎯 Interview One-Liner

“typeof null is 'object' (legacy bug). instanceof checks prototype chains but breaks across realms. Use Array.isArray to check arrays safely.”

7. 🧮 Type Conversion (Explicit vs Implicit)

✅ Explicit

Number("42") → 42
String(123) → "123"
Boolean(0) → false

✅ Implicit (coercion)

1 + "2" → "12" (string concatenation).
1 - "2" → -1 (string → number).
[] + [] → "" (empty string).
[] + {} → "[object Object]".
{} + [] → 0 (parsed as block + array).

⚠️ Gotchas

[] == ![]; // true
// [] -> "" -> 0, ![] -> false -> 0

🎯 Interview One-Liner

“Type coercion is implicit conversion. Addition prefers strings, subtraction prefers numbers. Weird cases like [] + {} = '[object Object]' are from toString/valueOf conversions.”

🟦 Core JavaScript — Expert-Level Revision

🟦 Error Handling & Debugging

1. ⚠️ `try` / `catch` / `finally`

Definition:
Mechanism for handling runtime exceptions.

✅ Key Points

catch handles synchronous errors in the try block.
finally always executes (even if return/throw in try/catch).
Errors bubble up if unhandled.

⚠️ Gotchas

try {
  throw new Error("boom");
} catch (e) {
  return "handled";
} finally {
  return "finally"; // overrides catch return
}

🎯 Interview One-Liner

“finally always runs and overrides return values. Errors bubble up unless caught.”

2. 🕸️ Error Types in JavaScript

✅ Built-in Error Objects

Error → base class.
SyntaxError → invalid syntax (only at parse time).
ReferenceError → accessing undeclared variable.
TypeError → invalid operation (e.g., calling non-function).
RangeError → out-of-range numbers (e.g., invalid array length).
URIError → malformed URI in encodeURI/decodeURI.
EvalError → legacy, rarely used.

Example

try {
  JSON.parse("{ invalid }");
} catch (e) {
  console.log(e instanceof SyntaxError); // true
}

🎯 Interview One-Liner

“JS has typed errors: Syntax, Reference, Type, Range, URI. Most common in practice: TypeError and ReferenceError.”

3. 🛠️ Custom Errors

Definition:
Extend the Error class for domain-specific errors.

Example

class ValidationError extends Error {
  constructor(message) {
    super(message);
    this.name = "ValidationError";
  }
}
throw new ValidationError("Invalid input");

🎯 Interview One-Liner

“Custom errors extend Error and set a name for better debugging.”

4. ⚡ Async Error Handling

✅ Promises

fetch("bad-url")
  .then(res => res.json())
  .catch(err => console.error("Caught:", err));

.catch() handles errors in promise chain.
Uncaught rejections trigger unhandledrejection event.

✅ async/await

async function getData() {
  try {
    await fetch("bad-url");
  } catch (err) {
    console.error("Caught:", err);
  }
}

Must wrap await in try/catch.
Rejections not caught will bubble like exceptions.

🎯 Interview One-Liner

“Promise errors bubble until caught. In async/await, use try/catch around awaits. Unhandled rejections trigger a global event.”

5. 🌍 Global Error Handling

✅ Browser

window.onerror = (msg, url, line, col, err) => {
  console.error("Global error:", msg, err);
};
window.onunhandledrejection = e => {
  console.error("Unhandled rejection:", e.reason);
};

✅ Node.js

process.on("uncaughtException", err => { ... });
process.on("unhandledRejection", err => { ... });

⚠️ Gotchas

Don’t rely on global handlers as the only mechanism — they’re last resort.
Use for logging/alerting in production.

🎯 Interview One-Liner

“Global error handlers (window.onerror, onunhandledrejection) are safety nets — good for logging, but not a replacement for local handling.”

6. 🧭 Debugging Techniques

✅ Tools

console.* (log, warn, error, table, dir).
debugger keyword (pauses execution in DevTools).
Source maps (map minified code to original).

✅ Advanced

Performance profiling (DevTools Performance tab).
Memory profiling (heap snapshots, allocation timelines).
Break on DOM mutation.

🎯 Interview One-Liner

“Use console, debugger, and source maps for debugging. For perf/memory, use DevTools profiling and heap snapshots.”

7. 📋 Best Practices for Error Handling

Fail fast, fail safe → throw early, recover gracefully.
Don’t swallow errors (catch(e){} with empty body).
Normalize errors (consistent structure across app).
Log with context (user action, environment).
Avoid throwing strings, always throw new Error(...).
Separate expected errors (validation) from unexpected ones (bugs).

🎯 Interview One-Liner

“Best practice: never swallow errors, always throw Error objects, separate expected from unexpected, and log with context.”

🟦 Core JavaScript — Expert-Level Revision

🟦 Concurrency & Parallelism

1. 🧵 Single-Threaded Model

Definition:
JavaScript executes on a single thread (the call stack) with concurrency simulated via the event loop.

✅ Key Points

JS can’t run two functions truly in parallel on the main thread.
Concurrency = overlapping tasks (via async callbacks).
Parallelism = tasks literally executing at the same time (needs threads/workers).

⚠️ Gotchas

Long-running tasks block UI → “frozen page”.
Async doesn’t mean parallel (Promises still run on one thread).

🎯 Interview One-Liner

“JavaScript is single-threaded; concurrency comes from the event loop, but real parallelism requires workers.”

2. ⏳ Concurrency via Event Loop

Definition:
The event loop interleaves tasks from macrotask & microtask queues.

✅ Key Points

Concurrency = cooperative multitasking.
No two JS functions run at the same instant on the same thread.

Example

setTimeout(() => console.log("timer"), 0);
Promise.resolve().then(() => console.log("promise"));
// Output: promise, timer

🎯 Interview One-Liner

“Concurrency in JS is managed by the event loop — tasks interleave but don’t run truly in parallel.”

3. ⚡ Parallelism via Web Workers

Definition:
Web Workers run JS in background threads separate from the main UI thread.

✅ Key Points

Communicate via postMessage (structured cloning).
No direct DOM access.
Useful for CPU-heavy tasks.

⚠️ Gotchas

Serialization overhead for large messages.
No shared state by default (copy-on-message).
Debugging workers is harder than main thread code.

Example

// worker.js
self.onmessage = e => self.postMessage(e.data * 2);

// main.js
const w = new Worker("worker.js");
w.onmessage = e => console.log(e.data);
w.postMessage(10); // 20

🎯 Interview One-Liner

“Web Workers provide real parallelism by running JS in separate threads, but can’t touch the DOM and communicate only via messages.”

4. 🧩 SharedArrayBuffer & Atomics

Definition:
APIs for shared memory and low-level synchronization between workers.

✅ Key Points

SharedArrayBuffer: allows multiple threads to view/edit same memory.
Atomics: provides atomic operations (safe increments, waits, notifications).
Enables building locks, semaphores, and concurrent data structures in JS.

⚠️ Gotchas

Very advanced — rarely used directly, but underpins WebAssembly multithreading.
Security concerns → disabled after Spectre/Meltdown, re-enabled with stricter cross-origin isolation.

Example

const buffer = new SharedArrayBuffer(4);
const arr = new Int32Array(buffer);

Atomics.store(arr, 0, 42);
console.log(Atomics.load(arr, 0)); // 42

🎯 Interview One-Liner

“SharedArrayBuffer + Atomics let workers share memory and coordinate safely. It’s how JS supports real multithreading in WebAssembly.”

5. 🧮 Parallelism in Node.js

Definition:
Node is single-threaded per process, but offers parallelism.

✅ Key Points

Worker Threads (since Node 10.5) → parallel JS execution.
Child Processes → true OS-level processes.
Cluster Module → multiple processes sharing load.
libuv threadpool → parallelize I/O and certain CPU tasks (crypto, fs).

🎯 Interview One-Liner

“Node achieves parallelism with worker threads, child processes, or libuv’s threadpool — though the main JS thread is single.”

6. 🏎️ Practical Uses of Parallelism

Image processing in background via workers.
Large JSON parsing → offload to worker to avoid UI freeze.
Concurrent fetch requests → concurrency (not parallelism).
WebAssembly with threads → real CPU parallelism.

🟦 Core JavaScript — Expert-Level Revision

🟦 ESNext & Modern Features

1. 🔢 BigInt

Definition:
A primitive type for arbitrarily large integers.

✅ Key Points

Append n → 123n.
Can’t mix with normal Number without explicit conversion.
No precision loss for huge numbers.

⚠️ Gotchas

2n + 3; // TypeError (can’t mix BigInt and Number)
Number(2n) === 2; // true

🎯 Interview One-Liner

“BigInt represents integers beyond Number’s 2^53-1 limit. You can’t mix it with Number — must explicitly convert.”

2. 🧩 Optional Chaining (`?.`)

Definition:
Safe property access without throwing if intermediate is null/undefined.

✅ Key Points

Short-circuits if value is null/undefined.
Works with properties, function calls, array indexes.

Example

const user = {};
console.log(user.profile?.email); // undefined, not error
console.log(user.getName?.());    // undefined

🎯 Interview One-Liner

“Optional chaining avoids errors by short-circuiting on null/undefined. It works for props, calls, and arrays.”

3. 🟰 Nullish Coalescing (`??`)

Definition:
Provides a fallback only for null/undefined, not falsy values.

✅ Key Points

0 || 42;   // 42
0 ?? 42;   // 0

"" || "x"; // "x"
"" ?? "x"; // ""

🎯 Interview One-Liner

“?? differs from || by treating only null/undefined as missing. Falsy values like 0 and '' are kept.”

4. 🔄 Top-Level `await`

Definition:
Allows await at the top level of ES modules.

✅ Key Points

Only allowed in ES modules (type="module").
Blocks module evaluation until awaited promise resolves.

Example

// top-level-await.js
const data = await fetch("/api").then(r => r.json());
console.log(data);

🎯 Interview One-Liner

“Top-level await lets you use await outside functions in ES modules, pausing module execution until resolved.”

5. ♻️ WeakRefs & FinalizationRegistry

Definition:
APIs to reference objects without preventing GC.

✅ WeakRef

new WeakRef(obj) → creates weak reference.
.deref() returns object if still alive, else undefined.

✅ FinalizationRegistry

Lets you run cleanup after object GC (non-deterministic).

⚠️ Gotchas

Unreliable for program logic — GC is unpredictable.
Intended for caches, not control flow.

Example

let obj = { value: 123 };
const weak = new WeakRef(obj);

obj = null; // eligible for GC
console.log(weak.deref()); // maybe object, maybe undefined later

🎯 Interview One-Liner

“WeakRefs allow GC’d objects to be referenced weakly, and FinalizationRegistry lets you clean them up. Use for caches, not program logic.”

6. 📆 Temporal API (Proposal Stage 3)

Definition:
New Date/Time API to replace Date (which is broken).

✅ Key Points

Immutable, time zone aware, clear APIs.
Objects: PlainDate, PlainTime, ZonedDateTime, Duration.
Fixes DST bugs, leap second issues.

Example

import { Temporal } from "@js-temporal/polyfill";
const today = Temporal.Now.plainDateISO();
console.log(today.add({ days: 1 }).toString());

🎯 Interview One-Liner

“Temporal is the modern Date/Time API: immutable, time-zone aware, and accurate. It’s the future replacement for JS Date.”

7. 📦 Dynamic Import

Definition:
import() loads modules dynamically at runtime.

✅ Key Points

Returns a promise.
Enables conditional/lazy loading.
Used for code-splitting.

Example

if (condition) {
  const mod = await import("./math.js");
  mod.add(2, 3);
}

🎯 Interview One-Liner

“Dynamic import lets you load modules at runtime. It returns a promise, enabling conditional and lazy loading.”

8. 🎯 Logical Assignment Operators

Definition:
Shorthand operators for logical + assignment.

✅ Key Points

||= assigns if falsy.
&&= assigns if truthy.
??= assigns if null/undefined.

Example

let a = null;
a ||= 5;  // a = 5

let b = 0;
b ||= 5;  // b = 5
b ??= 5;  // b = 0 (unchanged)

🎯 Interview One-Liner

“Logical assignment operators (||=, &&=, ??=) combine short-circuiting with assignment. Handy for defaults and conditionals.”

9. 🧾 Numeric Separators

Definition:
Underscores in numbers for readability.

Example

const big = 1_000_000_000;
console.log(big); // 1000000000

🎯 Interview One-Liner

“Numeric separators make large numbers readable, but don’t affect the value.”

🟦 Core JavaScript — Expert-Level Revision

🟦 Patterns & Architecture in JavaScript

1. 📦 Module Pattern

Definition:
Encapsulates private state using closures, exposing only a public API.

✅ Key Points

Common before ES6 modules (import/export).
Uses IIFEs (Immediately Invoked Function Expressions).
Prevents polluting global scope.

Example

const Counter = (function () {
  let count = 0; // private
  return {
    inc: () => ++count,
    get: () => count,
  };
})();
console.log(Counter.inc()); // 1
console.log(Counter.count); // undefined

🎯 Interview One-Liner

“The module pattern hides implementation details with closures and exposes a controlled API. It was the precursor to ES modules.”

2. 👁️ Observer Pattern

Definition:
One-to-many dependency: when subject changes, observers are notified.

✅ Key Points

Basis for event systems.
Used in RxJS, MobX, DOM events.

Example

class Subject {
  constructor() { this.observers = []; }
  subscribe(fn) { this.observers.push(fn); }
  notify(data) { this.observers.forEach(fn => fn(data)); }
}
const subject = new Subject();
subject.subscribe(data => console.log("Got:", data));
subject.notify("Hello");

🎯 Interview One-Liner

“The observer pattern lets many listeners react when one subject changes. It underlies events, RxJS, and reactive libraries.”

3. 📡 Pub/Sub Pattern

Definition:
Decouples publishers from subscribers via a mediator (event bus).

✅ Key Points

Pub/Sub is like Observer but with a broker in between.
Subscribers don’t know who published the event.

Example

const bus = {};
bus.events = {};
bus.subscribe = (event, fn) =>
  (bus.events[event] = (bus.events[event] || []).concat(fn));
bus.publish = (event, data) =>
  (bus.events[event] || []).forEach(fn => fn(data));

bus.subscribe("login", user => console.log("Welcome", user));
bus.publish("login", "Alice");

🎯 Interview One-Liner

“Pub/Sub decouples producers and consumers with an event bus. Unlike Observer, subscribers don’t directly attach to the subject.”

4. 🧑‍🤝‍🧑 Singleton Pattern

Definition:
Restricts a class/module to a single instance.

✅ Key Points

Common for global state, config, caches.
Enforced via closures or static variables.

Example

class Singleton {
  constructor() {
    if (Singleton.instance) return Singleton.instance;
    Singleton.instance = this;
  }
}
const a = new Singleton();
const b = new Singleton();
console.log(a === b); // true

🎯 Interview One-Liner

“Singleton ensures one instance globally — useful for config, caches, or logging, but overuse makes testing harder.”

5. 🏭 Factory Pattern

Definition:
Function/class that creates objects without exposing the creation logic.

✅ Key Points

Encapsulates instantiation.
Can return different subclasses depending on arguments.

Example

function createUser(type) {
  if (type === "admin") return { role: "admin" };
  return { role: "guest" };
}
console.log(createUser("admin"));

🎯 Interview One-Liner

“Factory abstracts object creation, returning different variants without exposing constructor details.”

6. 🧩 Prototype Pattern

Definition:
Creates new objects by cloning existing ones.

✅ Key Points

In JS, all objects already inherit via prototypes.
Object cloning often uses Object.create(proto).

Example

const animal = { speak() { console.log("Hi"); } };
const dog = Object.create(animal);
dog.speak(); // "Hi"

🎯 Interview One-Liner

“Prototype pattern creates objects by cloning existing ones. In JavaScript, it’s built into the language via Object.create.”

7. 🧮 Functional Patterns (FP in JS)

✅ Immutability

Avoid mutating objects/arrays; use spread or Object.assign.

✅ Function Composition

const compose = (f, g) => x => f(g(x));
const double = x => x * 2;
const square = x => x * x;
console.log(compose(square, double)(3)); // (3*2)^2 = 36

✅ Pipeline (proposed `|>` operator)

More readable left-to-right function chaining.

🎯 Interview One-Liner

“FP patterns in JS emphasize immutability, pure functions, and composition. Composition allows small functions to build complex logic.”

8. ⚖️ Strategy Pattern

Definition:
Encapsulates interchangeable algorithms behind a common interface.

✅ Example

class Payment {
  setStrategy(strategy) { this.strategy = strategy; }
  pay(amount) { this.strategy.pay(amount); }
}
class Paypal { pay(a) { console.log("PayPal:", a); } }
class Stripe { pay(a) { console.log("Stripe:", a); } }

const payment = new Payment();
payment.setStrategy(new Paypal());
payment.pay(100); // PayPal: 100

🎯 Interview One-Liner

“Strategy encapsulates interchangeable algorithms, letting you switch behaviors dynamically.”

9. 🕵️ Decorator Pattern

Definition:
Adds functionality to objects without modifying them.

✅ Key Points

Popular in React (HOCs).
In ES, decorator syntax (@) is in proposal stage.

Example

function withLogging(fn) {
  return (...args) => {
    console.log("Args:", args);
    return fn(...args);
  };
}
const sum = (a, b) => a + b;
const loggedSum = withLogging(sum);
loggedSum(2, 3); // Logs args

🎯 Interview One-Liner

“Decorator adds behavior to functions or objects without modifying the original — e.g., React HOCs.”

10. 🕸️ Middleware Pattern

Definition:
Chain of functions where each step can process input and pass to next.

✅ Key Points

Popular in Express.js, Redux.
Flexible for cross-cutting concerns (logging, auth).

Example

function compose(middleware) {
  return function (ctx) {
    let i = 0;
    function next() {
      const fn = middleware[i++];
      if (fn) fn(ctx, next);
    }
    next();
  };
}
const fn = compose([
  (ctx, next) => { ctx.push("a"); next(); },
  (ctx, next) => { ctx.push("b"); next(); }
]);
const arr = [];
fn(arr);
console.log(arr); // ["a","b"]

🎯 Interview One-Liner

“Middleware composes a pipeline of functions where each can act and forward. Used in Express, Redux, Koa.”

✅ Summary (Full Handbook)

This handbook covers expert-level JavaScript concepts in depth:

Closures, Scope, Hoisting, this, Prototypes, Event Loop
Asynchronous JavaScript (Timers, Promises, async/await, Generators, Debounce/Throttle, rAF, Workers)
Advanced Objects & Memory (GC, Symbols, WeakMap/WeakSet, Descriptors, Proxy/Reflect, Immutability)
Advanced Functions & ES6+ (HOFs, Currying, Modules, Destructuring, Params, Iterables, Map/Set, ES6+)
Browser & DOM (Event Delegation, Reflow vs Repaint, DOM APIs, Storage, Security, Service Workers, CRP, Loading)
Performance & Optimization (Leaks, Lazy Loading, Tree-shaking, Web Vitals, Async Scheduling, Bundling, Rendering)
Advanced Types & Equality (Truthy/Falsy, == vs ===, NaN/-0, Object.is, Wrappers, typeof quirks, Coercion)
Error Handling & Debugging (try/catch, Error types, Custom errors, Async handling, Global handlers, Debugging)
Concurrency & Parallelism (Single-threaded model, Event Loop, Workers, SharedArrayBuffer, Node parallelism)
ESNext & Modern Features (BigInt, Optional Chaining, Nullish, Top-level await, WeakRefs, Temporal, Imports, Operators)
Patterns & Architecture (Module, Observer, Pub/Sub, Singleton, Factory, Prototype, FP, Strategy, Decorator, Middleware)

Fundamentals of Functional JavaScript

Animesh Pandey — Sat, 06 Mar 2021 13:40:30 +0000

Introduction

Is Functional Programming any style of code that utilizes functions? If only it was that simple!
Functions are indeed at the core of Functional Programming, but it's how we use those functions that make our implementation functional.

This article aims to lay down some fundamentals of Functional Programming, while mainly pertaining to their application in JavaScript, that will help you understand :

What are Functions?
Functions versus Procedures
Declarative versus Imperative Programming
Understanding Function Inputs and Outputs

These foundations will immensely aid you in grasping further concepts of Functional JavaScript, to be covered in future articles, if this one helps.

The next article will cover :

Function Purity (Pure versus Impure Functions)
Side Effects
Extracting and Containing Impurity
How all of this collectively defines what Functional Programming is, and why it is used
Is JavaScript a Functional Programming Language?
Why consider Functional Programming style for your code?

Stay tuned!

1. What are Functions?

Well, like any introductory programming class will tell you, a function is a reusable piece of code that performs some task upon execution. While this definition is reasonable, it misses out an important perspective that is the core of a function as it applies to Functional Programming.

Let's try to understand Functions more completely, with the example of very basic Mathematics.

You may remember reading about f(x) in school, or the equation y = f(x).
Let's assume the equation f(x) = x² - 1. What does that mean? What does it mean to graph that equation? Here's the graph:

It's equivalent to :

function f(x) {
   return Math.pow(x,2) - 1;
}

What you can notice is that for any value of x, say 1, if you plug it into the equation, you get 0. What is 0, though? It's the return value of the f(x) function, which we earlier said represents a y value.

In math, a function always takes input(s), and always gives an output. A term you'll often hear around FP is "morphism"; this is a fancy way of describing a set of values that maps to another set of values, like the inputs of a function related to the outputs of that function.

In our code, however, we can define functions with all sorts of input(s) and output(s), even though they'll rarely be interpreted as a visually plotted curve on a graph.

As such, a more complete definition of function would be :

A function is the semantic relationship between input and computed output.

Also note the usage of function and function throughout this article. While function is the concept we're discussing, function is just the JavaScript keyword.

Essentially, Functional Programming is about embracing using functions as functions in this mathematical sense.

2. Functions vs Procedures?

The terms Functions and Procedures are often used interchangeably, but they actually mean different things.

A Procedure is an arbitrary collection of functionality. It may have inputs, it may not. It may have an output (as a return value), it may not.

Whereas, a Function takes input(s) and definitely always has a return value.

For Functional Programming, we use functions as much as possible, and trying to avoid procedures wherever possible. All your functions should take input(s) and return output(s).

Based upon this knowledge, let's consider the following example :

// Example 1: Function or Procedure?

function addPokémon(team1 = 0, team2 = 0, team3 = 0) {
    var total = team1 + team2 + team3;
    console.log(total);
}

function countPokémon(currentTeam = 6, ...args) {
    return addPokémon(currentTeam, ...args);
}

countPokémon();
// Output : 6

countPokémon(6, 5, 6);
// Output : 17

Try to assess whether function addPokémon and countPokémon are functions or procedures?

Here are some basic observations :

addPokémon has a defined input, but no output specified by return. It should be a procedure.
countPokémon has a defined input and a defined return, so it should be a function?

We're correct about addPokémon being a procedure, but countPokémon is also a procedure, and not a function, since it makes a call to a procedure within itself.

In summary :

Note that a function that calls a procedure within itself, is also a procedure. The "impurity" of a procedure, which is a concept to be explained further down, trickles down and "pollutes" all those who directly or indirectly call it.

Now, we would probably like to understand how to convert the last example's procedures into functions?

Based on the more complete definition of a function mentioned in the last section, try to make changes to the last example, before looking ahead for one of many possible solutions. For this example, it should be pretty straight-forward.

// Example 2: Converting Procedures to Functions?

function addPokémon(team1 = 0, team2 = 0, team3 = 0) {
    var total = team1 + team2 + team3;
    return total;
    // Instead of logging a value, we returned it,
    // so there's a proper output/return now.
}

function countPokémon(currentTeam = 6, ...args) {
    return addPokémon(currentTeam, ...args);
    // Now, a call to a function, not a procedure, is returned
}

console.log(countPokémon());
// Output : 6

console.log(countPokémon(6, 5, 6));
// Output : 17

Let's look at one more example for differentiating procedures and functions.

// Example 3. Identifying functions and procedures

function neighbouringPokémonID(x) {
    x = Number(x);
    return [x - 1, x + 1];
}

function generateNeighboursForTeam(team) {
    var teamIDs = Object.keys(team);
    teamIDs.forEach(element => 
        console.log(neighbouringPokémonID(element)));
}

var myTeam = {
    25: "Pikachu",
    155: "Cyndaquil"
};

generateNeighboursForTeam(myTeam);
// Output :
// [24, 26]
// [154, 156]

This snippet effectively returns the Pokédex IDs of the immediate neighbours of a Pokémon, given its own ID.

Clearly, neighbouringPokémonID is a function, as it has an input and returns an output based upon it.

Also, generateNeighboursForTeam is a procedure, as it doesn't return anything.

Once again, we can modify this example such that both are functions.

// Example 4. Converting the procedure to a function

function neighbouringPokémonID(x) {
    x = Number(x);
    return [x - 1, x + 1];
}

function generateNeighboursForTeam(team) {
    var teamIDs = Object.keys(team);
    var neighbourIDs = [];
    // Use a temporary array to store computation
    teamIDs.forEach(element =>
        neighbourIDs.push(neighbouringPokémonID(element)));
    return neighbourIDs;
}

var myTeam = {
    25: "Pikachu",
    155: "Cyndaquil"
};

generateNeighboursForTeam(myTeam);
// Output :
// [[24, 26],[154, 156]]

3. Declarative vs Imperative Programming?

Another basic concept to be familiar with is, the distinction between Declarative and Imperative styles of coding, which is honestly a bit relative in its meaning.

There's no style that's absolutely Declarative or absolutely Imperative. It's a spectrum in itself.

That said, let's introduce ourselves to a common, simple definition.

“Imperative programming is like how you do something, and Declarative programming is more like what you do.”

It's a bit ambiguous and open-ended, so let's take a small example.

Suppose, you are trying to help your little brother with the basics of the latest Pokémon game. Specifically, about catching wild Pokémon.

Declarative: Throw a pokéball when the pokémon is weak. (What to do)

Imperative: When the health bar of the pokémon is below 30%, press X to throw a pokéball. (Exactly how to do it)

In general, explicitly listing out all the steps one by one, is Imperative. It's rather robotic to understand, and requires going through it line by line.

And utilizing some level of abstraction and trusted helper functions, to list the steps in a manner in which it only presents the basic idea, is Declarative. It's easier to understand, as we don't need to bother about how something is happening, rather what is happening.

As what and how can be rather subjective, we can't draw a hard boundary around what is declarative or imperative.

For example, for a person programming in machine language, which is super imperative, Java can seem rather declarative. Or for a person who works on a purely functional language, like Haskell or Clojure, even functional implementations in JavaScript can feel rather imperative.

Our concern at the moment, which is to set the foundations of Functional Programming and Functional JavaScript, we need to understand that we should make our code as declarative as possible, by utilizing functions.

Moving on, let's understand a bit more about Function Inputs and Outputs.

4. Function Inputs

This section covers some more aspects of Function Inputs, chiefly :

Arguments and Parameters
Defaulting Parameters
Counting Inputs
Arrays of Arguments
Parameter Destructuring
Benefits of Declarative Style
Named Arguments
Unordered Parameters

Let's get started.

a. Arguments and Parameters

There's often a slight confusion about the difference between arguments and parameters.

Put simply, arguments are the values you pass into a function, and parameters are the named variables inside the function that receive those values.

Note: In JavaScript, the number of arguments do not need to match the number of parameters. If you pass more arguments than you have declared parameters to receive them, the values pass in just fine.

These extra arguments can be accessed in a few ways, including the args object. If you pass fewer arguments, each unmatched parameter is assigned undefined.

b. Defaulting Parameters

Parameters can declare default values. In the case where the argument for that parameter is not passed, or it's passed the value undefined, the default assignment expression is substituted.

function f(x = 10) {
    console.log(x);
}

f();                // Output : 10
f(undefined);       // Output : 10
f(null);            // Output : null
f(0);               // Output : 0

It's always a good practice to think about any default cases that can aid the usability of your functions.

c. Arity, or Count of Inputs

The number of arguments a function "expects" is determined by the number of parameters that are declared.

function f(x,y,z,w) {
    // something
}

f.length;
// Output :
// 4

f(..) expects 4 arguments, as it has 4 declared parameters. This count has a special term: Arity, which is the number of parameters in a function declaration. The arity of f(..) is 4.

Furthermore, a function with arity 1 is additionally called unary, a function with arity 2 is also called binary, and a function with arity 3 or higher is named n-ary.

The length property of that function reference returns its arity.

While this may sound simple, the implications are far-reaching.

One reason for determining the arity during execution would be if a piece of code received a function reference from multiple sources, and has to send different values depending on the arity of each.

For example, let's say a fn function reference could expect one, two, or three arguments, but you always want to just pass a variable x in the last position:

// `fn` is set to some function reference
// `x` exists with some value

if (fn.length == 1) {
    fn(x);
}
else if (fn.length == 2) {
    fn(undefined, x);
}
else if (fn.length == 3) {
    fn(undefined, undefined, x);
}

Tip: The length property of a function is read-only and it's determined at the time you declare the function. It should be thought of as essentially a piece of metadata that describes something about the intended usage of the function.

One gotcha to be aware of is that certain kinds of parameter list variations can make the length property of the function report something different than you might expect:

function foo(x,y = 2) {
    // something
}

function bar(x,...args) {
    // something
}

function baz( {a,b} ) {
    // something
}

foo.length;             // Output : 1
bar.length;             // Output : 1
baz.length;             // Output : 1

What about counting the number of arguments the current function call received? This was once trivial, but now the situation is slightly more complicated. Each function has an arguments object (array-like) available that holds a reference to each of the arguments passed in. You can then inspect the length property of arguments to figure out how many were actually passed:

function f(x,y,z) {
    console.log(arguments.length);
}

f(3, 4);   
// Output : 
// 2

As of ES5 (and strict mode, specifically), arguments is considered by some to be sort of deprecated; many avoid using it if possible. However, arguments.length, and only that, is okay to keep using for those cases where you need to care about the passed number of arguments.

A function signature that accepts an indeterminate amount of arguments is referred to as a variadic function.

Say you do need to access the arguments in a positional array-like way, possibly because you're accessing an argument that doesn't have a formal parameter at that position. How do we do it?

ES6 to the rescue! Let's declare our function with the ... operator, referred to as "spread", "rest", or "gather":

function f(x,y,z,...args) {
    // something
}

The ...args in the parameter list is an ES6 declarative form that tells the engine to collect all remaining arguments (if any) not assigned to named parameters, and put them in a real array named args. args will always be an array, even if it's empty. But it will not include values that are assigned to the x, y, and z parameters, only anything else that's passed in beyond those first three values.

function f(x,y,z,...args) {
    console.log(x, y, z, args);
}

f();                // undefined undefined undefined []
f(1, 2, 3);         // 1 2 3 []
f(1, 2, 3, 4);      // 1 2 3 [ 4 ]
f(1, 2, 3, 4, 5);   // 1 2 3 [ 4, 5 ]

So, if you want to design a function that can account for an arbitrary number of arguments, use ...args.

You can use the ... operator in the parameter list even if there are no other formal parameters declared.

function (...args) {
    // something
}

args will now be the complete array of arguments, whatever they are, and you can use args.length to know exactly how many arguments have been passed in.

d. Arrays of Arguments

What if you wanted to pass along an array of values as the arguments to a function call?

function f(...args) {
    console.log(args[3]);
}

var arr = [1, 2, 3, 4, 5];
f(...arr);  
// Output :                    
// 4

Our new friend, the ... operator is used here, but now not just in the parameter list; it's also used in the argument list at the call-site.

It has the opposite behavior in this context.
In a parameter list, we said it gathered arguments together. In an argument list, it spreads them out. So the contents of arr are actually spread out as individual arguments to the f(..) call.

Also, multiple values and ... spreadings can be interweaved, as needed:

var arr = [2];

f(1, ...arr, 3, ...[4,5]);  
// Output :   
// 4

Think of ... in this symmetric sense: in a value-list position, it spreads. In an assignment position -- like a parameter list, because arguments get assigned to parameters -- it gathers.

... makes working with arrays of arguments much easier.

e. Parameter Destructuring

Consider the variadic f(..) from the previous section:

function f(...args) {
    // something
}

f( ...[1,2,3]);

What if we wanted to change that interaction so the caller of our function passes in an array of values instead of individual argument values? Just drop the two ... usages:

function f(args) {
    // something
}

f([1,2,3]);

Simple enough. But what if now we wanted to give a parameter name to each of the first two values in the passed-in array? We aren't declaring individual parameters anymore, so it seems we lost that ability.

Thankfully, ES6 destructuring is the answer. Destructuring is a way to declare a pattern for the kind of structure (object, array, etc.) that you expect to see, and how decomposition (assignment) of its individual parts should be processed.

Consider:

function f([x,y,...args] = []) {
    // something
}

f([1,2,3]);

Do you spot the [ .. ] brackets around the parameter list now? This is called array parameter destructuring.

In this example, destructuring tells the engine that an array is expected in this assignment position (aka parameter). The pattern says to take the first value of that array and assign it to a local parameter variable called x, the second to y, and whatever is left is gathered into args.

f. Benefits of Declarative Style

Considering the destructured f(..) we just looked at, we could instead have processed the parameters manually:

function f(params) {
    var x = params[0];
    var y = params[1];
    var args = params.slice(2);
    // something
}

But here we highlight a principle that declarative code communicates more effectively than imperative code.

Declarative code (for example, the destructuring in the former f(..) snippet, or the ... operator usages) focuses on what the outcome of a piece of code should be.

Imperative code (such as the manual assignments in the latter snippet) focuses more on how to get the outcome. The outcome is coded there, but it's not as clear because it's crowded by the details of how we got there.

The earlier f(..) is regarded as more readable, because the destructuring hides the unnecessary details of how to manage the parameter inputs.

Wherever possible, we should strive for declarative, self-explanatory code.

g. Named Arguments

Just as we can destructure array parameters, we can destructure object parameters:

function f({x,y} = {}) {
    console.log(x, y);
}

f({
    y: 3
});
// Output :                                      
// undefined 3

We pass in an object as the single argument, and it's destructured into two separate parameter variables x and y, which are assigned the values of those corresponding property names from the object passed in. It didn't matter that the x property wasn't on the object; it just ended up as a variable with undefined like you'd expect.

With a normal call-site like f(undefined,3), position is used to map from argument to parameter; we put the 3 in the second position to get it assigned to a y parameter.

But at this call-site where parameter destructuring is involved, a simple object-property indicates which parameter (y) the argument value 3 should be assigned to.

Some languages have an explicit feature for this: named arguments. In other words, at the call-site, labeling an input value to indicate which parameter it maps to. JavaScript doesn't have named arguments, but parameter object destructuring is the next best thing.

h. Unordered Parameters

Another key benefit is that named arguments, by virtue of being specified as object properties, are not fundamentally ordered. That means we can specify inputs in whatever order we want:

function f({x,y} = {}) {
    console.log(x, y);
}

f({
    y: 3
});  
// Output :                  
// undefined 3

The call-site is no longer cluttered by ordered-placeholders like undefined to skip a parameter.

Function Outputs

This section covers some more aspects of Function Outputs.

In JavaScript, functions always return a value. These three functions all have identical return behavior:

function foo() {}

function bar() {
    return;
}

function baz() {
    return undefined;
}

The undefined value is implicitly returned if you have no return or if you just have an empty return;.

But keeping as much with the spirit of Functional Programming function definition as possible -- using functions and not procedures -- our functions should always have outputs, which means they should explicitly return a value, and usually not undefined.

A return statement can only return a single value. So if your function needs to return multiple values, your only viable option is to collect them into a compound value like an array or an object:

function f() {
    var retValue1 = 1;
    var retValue2 = 3;
    return [retValue1, retValue2];
}

Then, we'll assign x and y from two respective items in the array that comes back from f():

var [x, y] = f();
console.log(x + y);
// Output : 4

Collecting multiple values into an array (or object) to return, and subsequently destructuring those values back into distinct assignments, is a way to transparently express multiple outputs for a function.

Let's cover some concepts related to Function Outputs, chiefly :

Early Returns
Unreturned Outputs
Higher-Order Functions (HOFs or Functions of Functions)

a. Early Returns

The return statement doesn't just return a value from a function. It's also a flow control structure; it ends the execution of the function at that point.

A function with multiple return statements thus has multiple possible exit points, meaning that it may be harder to read a function to understand its output behavior if there are many paths that could produce that output.

Consider:

function f(x) {
    if (x > 10) return x + 1;

    var y = x / 2;

    if (y > 3) {
        if (x % 2 == 0) return x;
    }

    if (y > 1) return y;

    return x;
}

f(2);    // Output : 2
f(4);    // Output : 2
f(8);    // Output : 8
f(12);   // Output : 13

First off, f(x) is highly unreadable and difficult to follow. Dry-running this in your mind is quite tedious. That's because we're using return not just to return different values, but also as a flow control construct to quit a function's execution early in certain cases.

Consider this version of the code:

function f(x) {
    var retValue;

    if (retValue == undefined && x > 10) {
        retValue = x + 1;
    }

    var y = x / 2;

    if (y > 3) {
        if (retValue == undefined && x % 2 == 0) {
            retValue = x;
        }
    }

    if (retValue == undefined && y > 1) {
        retValue = y;
    }

    if (retValue == undefined) {
        retValue = x;
    }

    return retValue;
}

This version is unquestionably more verbose. But it is slightly simpler logic to follow, because every branch where retValue can get set is guarded by the condition that checks if it's already been set.

Rather than returning from the function early, we used normal flow control (if logic) to determine the retValue's assignment. At the end, we simply return retValue.

In summary, it's more readable to have just a single return at the end. Try to figure out the most explicit way to express the logic.

b. Un`return`ed Outputs

One technique that you've probably used in most code you've written, and maybe didn't even think about it much, is to have a function output some or all of its values by simply changing variables outside itself.

Remember our f(x) = x² - 1 function from earlier? We could have defined it like this in JS:

var y;
function f(x) {
    y = (2 * Math.pow( x, 2 )) + 3;
}

We could just as easily have returnd the value instead of setting it into y from within the function:

function f(x) {
    return (2 * Math.pow( x, 2 )) + 3;
}

Both functions accomplish the same task, so is there any reason we should pick one version over the other?

One way to explain the difference is that the return in the latter version signals an explicit output, whereas the y assignment in the former is an implicit output.

But changing a variable in an outer scope, as we did with the y assignment inside of f(..), is just one way of achieving an implicit output. A more subtle example is making changes to non-local values via reference.

Consider:

function sum(list) {
    var total = 0;
    for (let i = 0; i < list.length; i++) {
        if (!list[i]) list[i] = 0;
        total = total + list[i];
    }
    return total;
}

var nums = [ 1, 3, 9, 27, , 84 ];
sum(nums);
// Output : 
// 124

The most obvious output from this function is the sum 124, which we explicitly returned. But instead of an undefined empty slot value in position 4, now there's a 0.

The harmless looking list[i] = 0 operation ended up affecting the array value on the outside, even though we operated on a local list parameter variable.

Why? Because list holds a reference-copy of the nums reference, not a value-copy of the [1,3,9,..] array value. JavaScript uses references and reference-copies for arrays, objects, and functions, so we may create an accidental output from our function all too easily.

This implicit function output has a special name in the FP world: Side Effects. And a function that has no side effects also has a special name: Pure Function. Both these concepts will be covered in the next article.

c. Higher-Order Functions (HOFs or Functions of Functions)

Functions can receive and return values of any type. A function that receives or returns one or more other function values has the special name: higher-order function.

Consider:

function forEach(list,fn) {
    for (let v of list) {
        fn( v );
    }
}

forEach( [1,2,3,4,5], function each(val){
    console.log( val );
} );

// Output :
// 1 2 3 4 5

forEach(..) is a higher-order function because it receives a function as an argument.

A higher-order function can also output another function, like:

function f() {
    return function upper(x){
        return x.toUpperCase();
    };
}

var g = f();
g("Hello!");

// Output :
// HELLO!

return is not the only way to "output" an inner function:

function f() {
    return g(function upper(x){
        return x.toUpperCase();
    } );
}

function g(func) {
    return func("Hello!");
}

f();

// Output :
// HELLO!

Functions that treat other functions as values are higher-order functions by definition. These are very crucial to Functional Programming!

Summary

We covered the following concepts in this article :

What are Functions?
Functions versus Procedures
Declarative versus Imperative Programming
Function Inputs
- Arguments and Parameters
- Defaulting Parameters
- Counting Inputs
- Arrays of Arguments
- Parameter Destructuring
- Benefits of Declarative Style
- Named Arguments
- Unordered Parameters
Function Outputs
- Early Returns
- Unreturned Outputs
- Higher-Order Functions (HOFs or Functions of Functions)

The next article will cover :

Function Purity (Pure versus Impure Functions)
Side Effects
Extracting and Containing Impurity
How all of this collectively defines what Functional Programming is, and why it is used
Is JavaScript a Functional Programming Language?
Why consider Functional Programming style for your code?

Credits

Functional-Light JS book by Kyle Simpson, for inspiring this article, as well as,
FrontEnd Masters : Functional-Light JavaScript

Thanks a lot for reading! ❤️

Follow me?

How well do you know “this”?

Animesh Pandey — Sun, 28 Feb 2021 01:07:45 +0000

What’s “this”?

In the simplest of terms, the JavaScript keyword this refers to the object it belongs to on runtime, depending upon its call-site (where it is called).

However, understanding what it would refer to in any given context, requires a slightly deeper understanding of some relevant concepts, which will be covered in this article.

Just to start with, this can have the following values depending upon where it is accessed :

By default : this refers to the global object.
Inside a function : this refers to the global object. In strict mode, however, this will be undefined.
Inside a method : this refers to the owner object. (A method is a function that belongs inside an object. In other words, it’s a function that’s an object’s property.)
In an event: this refers to the element on which the event was triggered.
Inside an Immediately Invoked Function Expression (IIFE) : this refers to the global object. In strict mode, this will be undefined, just like any other function in a global context.
Inside a Fat-Arrow function: When a fat arrow ()=> is used to define a function, it doesn’t create a new value for this, instead, it keeps referring to the same object it was referring to outside of the function.

This article hopes to give you an understanding of how these values are assigned to this, and how this knowledge can be utilized to suit our requirements.

Call-Site and Call-Stack

As discussed in the last section, we got to know that this is a runtime-binding made for each function invocation, which entirely depends upon where exactly it was called.

This location in the code where the concerned function was called, is called the call-site. An understanding of determining the call-site is crucial towards understanding what this would be bound to, at any given point of the execution.

While finding the call-site is generally as simple as locating where a function was called from, it might not always be that clear because of certain coding patterns that might obscure it.

Hence, it’s important to think about the call-stack, the stack of functions that have been called to get us to the current stage of the execution which we’re concerned with.

Let us take a simple example to illustrate how a call-stack and call-site could be determined.

By following the chain of function calls in order, you can determine the call-stack and call-sites.

* Tip for determining call-stack

Utilize the built-in JS debugger provided with any modern browser’s developer tools.

In the execution of any JS code, you can set a breakpoint by using the keyword debugger, to stop the execution at that point in the browser.

Let’s say, we add a breakpoint when thunderbolt() was called.

The debugger stops the execution at the custom breakpoint, and the function call-stack at that point can be viewed on the right side.

In the image above, we can see that the execution was stopped at the point where we mentioned the debugger keyword, as soon as thunderbolt() is called. At this point, we will not observe any execution of code that comes after the debugger (just the thunderbolt() log, in this case).

Our primary point of interest right now, is the call-stack which is clearly illustrated on the right-hand side, same as we determined in the example above. (anonymous) at the bottom of the stack, refers to the initial global call to choosePikachu().

Binding rules for “this”

Now that we understand what a call-site and a call-stack is, we can learn about how a call-site determines what this will hold during execution.

There are four general rules which apply. First, let’s understand them independently, and then, their order of precedence when multiple rules can apply to the call-site.

1. Default Binding

This is the default catch-all rule, when none others apply. It comes from the most common case of a function invocation, which a standalone function call.

Let’s look at the below example.

The variable ultraBall declared in global scope is the same as declaring a property on the global object of the same name.

Inside getPokemon(), the reference to this defaults to the global object. Hence, we would see the value of this.ultraBall getting logged.

However, if strict mode is in effect globally or inside getPokemon, the global object is not permitted default binding. In that case, we will see the error TypeError : 'this' is 'undefined'.

2. Implicit Binding

If the call-site has a context object (if a function is called through an owning or containing object, as its property), implicit binding applies.

The rule states that, when there is a context object for a function reference, it’s that object that should be used for its method calls’ this binding.

Let’s look at a few examples to illustrate the different cases which can arise.

Since the object pikachu is the this for the getBaseSpeed call, this.baseSpeed is synonymous to pikachu.baseSpeed.

Let’s look at another example to see how only the top or last level of an Object property reference chain matters to the call-site for implicit this binding.

As we can see, the baseSpeed value is still 90. That’s because the call to getBaseSpeed is bound to its direct caller, pikachu, which serves as its this binding. In this context, the baseSpeedvalue is 90.

Let’s look at a few more examples to show common cases where implicit binding can seem unexpected.

In this example, we have lost our implicit this binding to pikachu in case of assigning pikachu.getBaseSpeed to a different variable baseSpeedFunction. Now, for baseSpeedFunction, this refers to the global object (default binding takes place). Hence, for the call, this.baseSpeed will be 50.

Now, a more common and not-so-obvious way this loss of implicit binding can occur is when we pass a callback function. Consider the following example :

Once again, inside the callback function executor executeFunction, we are effectively passing a reference to pikachu.getBaseSpeedfunction. Upon execution, this will be bound to the global object again (or throw a TypeError, if strict mode is enabled), instead of pikachu.

It’s quite common for function callbacks to lose their this binding. Another unexpected outcome can arise when the function we’ve passed our callback to, intentionally alters the this for the call. For example, Event handlers in popular JavaScript libraries often modify this to point to the DOM element that triggered the event.

You are not really in control of how your callback function reference will be executed. So far, you don’t have any way of controlling the call-site to assign the binding you intended. This is where explicit binding comes into play.

3. Explicit Binding

To resolve the unintended loss of this with implicit binding, we can explicitly set the value of this to a given object for a function call.

There are several in-built methods that can help us achieve explicit binding, like :

The bind() method

bind() is a method of the Function.prototype property. This means bind() can be used by every single function.

The bind() method creates a new function that, when called, has its this keyword set to the provided value, with a given sequence of arguments preceding any provided when the new function is called.

In other words, bind() returns a new function that is hardcoded to call the original function with the this context set as specified.

The call() and apply() methods

call() and apply() are also methods of the Function.prototype property, with similar but slightly different usage.

The call() method calls a function with a given this value and arguments provided individually.

Whereas, the apply() method calls a function with a given this value, and arguments provided as an array (or an array-like object).

Invoking Pokémon with explicit binding by Pokémon.call() or Pokémon.apply() allows us to force its this to be the this of function PokémonExtension.

Also, a noteworthy aspect of the above example is that all instances of PokémonExtension will bind their respective this to the execution of Pokémon within them. Such an explicit binding is also called hard binding.

4. new Binding

In JavaScript, there is really no such thing as “constructor functions”, but rather construction call of functions.

When a function is invoked with new in front of it, otherwise known as a constructor call, the following things are done automatically.

A brand new object is created (aka constructed) out of thin air.
The newly constructed object is [[Prototype]]-linked. (Out of the scope of this article)
The newly constructed object is set as the this binding for that function call.
Unless the function returns its own alternate object, the new invoked function call will automatically return the newly constructed object.

All binding rules in action

It should be clear that the default binding is the lowest priority rule of the four.

Let’s compare implicit binding, explicit binding, and new binding with each other.

Implicit versus Explicit

As we saw, the explicit binding of firstAttempt.catchPokémon with secondAttempt took precedence over its own implicit binding, as it did for the second case as well.

Hence, explicit binding is of higher precedence than implicit binding.

Implicit versus new

So, new binding is more precedent than implicit binding.

Explicit versus new?

new and call or apply cannot be used together, so something like var fourthAttempt = new catchPokémon.call(firstAttempt); is not allowed to test new binding directly against explicit binding. But, we can still use a hard binding to test the precedence of the two.

attemptBinder is hard-bound against firstAttempt, but new attemptBinder(“Steelix”) did not change firstAttempt.name to "Steelix", as we may have expected, but it remained "Onix".

Instead, the hard-bound call to attemptBinder("Steelix") is able to be overridden with new . Since new was applied, we got the newly created object back, which we named secondAttempt, and we see that secondAttempt.name indeed has the value "Steelix".

Thus, the newly created this is used, rather than the previously specified hard-binding for this. Effectively, new is able to override hard-binding.

The primary reason for this behaviour is to create a function that essentially ignores the this hard-binding, and presets some or all of the function’s arguments.

Finally, determining “this”

We can summarize the rules for determining this from a function call’s call-site, in their order of precedence.

Here they are :

Is the function called with new ? If so, this is the newly constructed object (New binding). Example, var attempt = new catchPokémon("Pidgey");
Is the function called with call or apply , even hidden inside a bind hard-binding? If so, this is the explicitly specified object (Explicit binding). Example, var attempt = catchPokémon.call("Pidgeotto");
Is the function called with a context, otherwise known as an owning or containing object? If so, this is that context object (Implicit binding). Example, var attempt = firstAttempt.catchPokémon("Pidgeot");
Otherwise, this defaults to the global object, or undefined in strict mode (Default binding).

Summary

Determining the this binding for an executing function requires finding the direct call-site of that function.

Once examined, four rules can be applied to the call site, in this order of precedence.

Called with new? Use the newly constructed object.
Called with call or apply or bind? Use the specified object.
Called with a context object owning the call? Use that context object.
Default : undefined in strict mode, global object otherwise.

Credits

Official documentation: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/this
You Don’t Know JS: this and Object Prototypes, by Kyle Simpson.

Forem: Animesh Pandey

[Boost]

Are Feature Flags Bullsh*t? Why Your "IF" is Killing Performance (and the Planet)

TypeScript Expert Revision Handbook

📑 Table of Contents

🟦 Fundamentals (Expert Level)

1. 🧩 Type System vs Runtime Behavior

✅ Key Points

⚠️ Gotchas

🎯 Interview One-Liner

2. 🔢 Core Primitive Types

✅ Basic Types

✅ Special Types

⚠️ Gotchas

🎯 Interview One-Liner

3. 🏷️ Type Assertions vs Casting

✅ Syntax

✅ Non-null Assertion

⚠️ Gotchas

🎯 Interview One-Liner

4. 🔍 Type Narrowing (Control Flow Analysis)

✅ Techniques

Example

⚠️ Gotchas

🎯 Interview One-Liner

5. 🚦 Strict Null Checking

✅ Example

✅ Optional Chaining + Nullish Coalescing

⚠️ Gotchas

🎯 Interview One-Liner

6. 🔎 Structural Typing (vs Nominal)

✅ Example

⚠️ Gotchas

🎯 Interview One-Liner

7. 📝 Type Aliases vs Interfaces

✅ Differences

Example

⚠️ Gotchas

🎯 Interview One-Liner

8. 📦 Enums vs Literal Types

✅ Enums

✅ Literal Unions

⚠️ Gotchas

🎯 Interview One-Liner

🟦 Advanced Types

1. ➕ Union & Intersection Types

✅ Union (|)

✅ Intersection (&)

⚠️ Gotchas

🎯 One-Liner

2. 🔢 Literal Types & Const Assertions

✅ Literal Types

✅ as const

🎯 One-Liner

3. 📝 Template Literal Types

✅ Key Points

✅ Use Cases

🎯 One-Liner

4. 🧮 Conditional Types

✅ Example

✅ Distributive Behavior

⚠️ Gotchas

🎯 One-Liner

5. 🗂️ Mapped Types

✅ Basics

✅ Modifiers

🎯 One-Liner

6. 🛠️ Utility Types

✅ Built-ins

Example

🎯 One-Liner

7. 🧩 Key Remapping in Mapped Types (TS 4.1+)

🎯 One-Liner

8. 🌀 Recursive & Deep Types

✅ Recursive Types

✅ Deep Utility

⚠️ Gotchas

🎯 One-Liner

🟦 Generics in Depth

1. 🧩 Generic Functions

✅ Union (`|`)

✅ Intersection (`&`)

✅ `as const`

2. 🔒 Constraints (`extends`)

✅ Typing `useState`

✅ Typing `useReducer`

5. 🧩 `any` vs `unknown` vs `never`

1. 📜 Ambient Declarations (`declare`)