JavaScript Deep Dive — Module 5: Expert Architecture & Design Patterns — JavaScript Deep Dive

Modules 1-4 gave you the engine's ground truth: memory, delegation, scheduling, and optimization. This capstone module is about what you build ON TOP of that ground truth -- disciplines and patterns that make large codebases predictable under change. None of this is language trivia; every technique here maps directly onto how a senior engineer structures real production systems.

1. Functional Programming Discipline

Functional programming in JavaScript is not about using .map() instead of a for loop -- it's a discipline of minimizing mutable, shared state so that data flow through a program is traceable and testable in isolation.

The four load-bearing concepts

Immutability: never mutate data in place -- produce a new value instead. This makes change trackable (you can diff old vs. new by reference) and eliminates an entire class of aliasing bugs from Module 1's pass-reference-by-value semantics
Pure Functions: given the same input, ALWAYS return the same output, and produce no observable side effects (no network calls, no mutation of arguments or outer state, no logging). Pure functions are trivially testable and safely memoizable
Higher-Order Functions (HOFs): functions that accept a function as an argument, return a function, or both -- .map/.filter/.reduce are HOFs; so is a function returning a configured validator
Currying & Composition: currying transforms a multi-argument function into a chain of single-argument functions, unlocking partial application; composition builds a new function by piping the output of one function into the input of the next, right to left (or left to right, if you use a pipe helper)

// BAD WAY (Don't Do This): mutates the caller's array in place -- a shared
// reference bug waiting to happen the moment two callers hold the same array.
function addItemBad(cart, item) {
  cart.push(item); // mutates the ORIGINAL array -- every other reference sees this
  return cart;
}

// ARCHITECT WAY (Do This): pure, immutable -- returns a NEW array, original untouched.
function addItemGood(cart, item) {
  return [...cart, item]; // spread copies existing elements into a fresh array
}

const original = [{ id: 1, name: 'Book' }];
const updated = addItemGood(original, { id: 2, name: 'Pen' });
console.log(original.length); // 1 -- untouched
console.log(updated.length);  // 2 -- new array

// Currying: unlocks reusable, partially-applied validators from one generic function.
const curry = (fn) => (...args) =>
  args.length >= fn.length
    ? fn(...args)
    : (...more) => curry(fn)(...args, ...more);

const isInRange = curry((min, max, value) => value >= min && value <= max);
const isValidAge = isInRange(0, 120);   // partially applied -- min/max locked in
console.log(isValidAge(45));            // true
console.log(isValidAge(-5));            // false

// Composition: build a data-processing pipeline from small, pure, single-purpose
// functions instead of one large imperative function.
const compose = (...fns) => (input) => fns.reduceRight((acc, fn) => fn(acc), input);

const trim = (s) => s.trim();
const toLowerCase = (s) => s.toLowerCase();
const collapseSpaces = (s) => s.replace(/\s+/g, ' ');

const normalizeSearchQuery = compose(collapseSpaces, toLowerCase, trim);
console.log(normalizeSearchQuery('  Senior  JS   Engineer  ')); // 'senior js engineer'

2. Advanced Design Patterns in Modern JavaScript

Classic Gang-of-Four patterns still apply to JavaScript, but the language's first-class functions and closures let you implement them with far less ceremony than in a purely class-based language.

// Observer / Pub-Sub: decouples event producers from consumers entirely --
// producers never need to know who (or how many) subscribers exist.
class EventBus {
  #listeners = new Map(); // eventName -> Set of handler functions

  on(eventName, handler) {
    if (!this.#listeners.has(eventName)) {
      this.#listeners.set(eventName, new Set());
    }
    this.#listeners.get(eventName).add(handler);
    return () => this.off(eventName, handler); // returns an unsubscribe function
  }

  off(eventName, handler) {
    this.#listeners.get(eventName)?.delete(handler);
  }

  emit(eventName, payload) {
    this.#listeners.get(eventName)?.forEach((handler) => handler(payload));
  }
}

const bus = new EventBus();
const unsubscribe = bus.on('order:placed', (order) => console.log('Ship it:', order.id));
bus.emit('order:placed', { id: 'ORD-1' }); // 'Ship it: ORD-1'
unsubscribe(); // clean teardown -- prevents the Module 4 'forgotten listener' leak pattern

// Singleton: exactly one instance, lazily created, shared everywhere it's imported.
// ES modules are cached by the runtime, so a module-scoped instance IS a singleton --
// no need for the classical 'private constructor + static getInstance()' dance.
class ConnectionPoolClass {
  #connections = [];
  constructor(size) {
    for (let i = 0; i < size; i++) this.#connections.push(`conn-${i}`);
  }
  acquire() { return this.#connections.pop(); }
  release(conn) { this.#connections.push(conn); }
}
export const ConnectionPool = new ConnectionPoolClass(10); // module cache guarantees singleton

// Factory: centralizes object CREATION logic so callers depend on a stable
// interface, not on which concrete class gets instantiated.
function createNotifier(channel) {
  const strategies = {
    email: (msg) => ({ send: () => console.log(`Emailing: ${msg}`) }),
    sms: (msg) => ({ send: () => console.log(`Texting: ${msg}`) }),
    push: (msg) => ({ send: () => console.log(`Push notify: ${msg}`) }),
  };
  const build = strategies[channel];
  if (!build) throw new Error(`Unknown channel: ${channel}`);
  return build; // returns a function; caller never touches a concrete class
}

createNotifier('sms')('Order shipped').send(); // 'Texting: Order shipped'

3. Metaprogramming: Proxy and Reflect

A Proxy wraps a target object and lets you intercept fundamental operations on it -- property reads, writes, deletions, function calls -- via a handler object of trap functions. Reflect is the companion API providing the DEFAULT implementation of each of those same operations, so a trap can delegate back to normal behavior instead of reimplementing it from scratch.

Why Proxy + Reflect together, not Proxy alone

Every trap (get, set, has, deleteProperty, etc.) receives the same arguments Reflect's matching method expects -- so Reflect.get(target, prop, receiver) inside a get trap is the correct default behavior, not a manual target[prop]
Using target[prop] directly inside a get trap breaks the receiver chain in subtle ways when the proxy is used as another object's prototype -- Reflect.get correctly forwards the receiver, target[prop] does not
This Proxy+Reflect pairing is exactly the mechanism Vue 3's reactivity system is built on: reads inside a component's render function are intercepted by a get trap that registers a dependency, and writes are intercepted by a set trap that triggers re-renders of everything that depends on the changed property

// A minimal reactive data-binding system -- the same core mechanic Vue 3's
// reactivity is built on, stripped down to its essential Proxy/Reflect mechanics.

let activeEffect = null; // the effect currently being tracked, if any
const targetMap = new WeakMap(); // target -> Map<property, Set<effect>>

function track(target, key) {
  if (!activeEffect) return; // no effect is currently running -- nothing to record
  let depsMap = targetMap.get(target);
  if (!depsMap) targetMap.set(target, (depsMap = new Map()));
  let dep = depsMap.get(key);
  if (!dep) depsMap.set(key, (dep = new Set()));
  dep.add(activeEffect);
}

function trigger(target, key) {
  const dep = targetMap.get(target)?.get(key);
  dep?.forEach((effect) => effect()); // re-run every effect that read this property
}

function reactive(target) {
  return new Proxy(target, {
    get(obj, key, receiver) {
      const result = Reflect.get(obj, key, receiver); // correct default read, receiver-aware
      track(obj, key); // record: activeEffect depends on obj[key]
      return result;
    },
    set(obj, key, value, receiver) {
      const result = Reflect.set(obj, key, value, receiver); // correct default write
      trigger(obj, key); // notify: obj[key] changed, re-run dependents
      return result;
    },
  });
}

function watchEffect(effectFn) {
  activeEffect = effectFn;
  effectFn(); // run once immediately to perform the initial dependency tracking
  activeEffect = null;
}

// USAGE: a fully working, minimal reactive counter with zero framework code.
const state = reactive({ count: 0 });

watchEffect(() => {
  console.log(`Count is now: ${state.count}`); // reading state.count registers this effect
});
// Logs immediately: 'Count is now: 0'

state.count++; // set trap fires trigger() -> re-runs the effect above automatically
// Logs: 'Count is now: 1'

Module 5 & Masterclass Recap

You've now built the complete mental model, top to bottom: memory and coercion mechanics (Module 1), the prototype chain and this binding (Module 2), the Event Loop and Promise internals (Module 3), V8's JIT and garbage collector (Module 4), and finally, the architectural disciplines -- functional programming, classic design patterns adapted to closures and modules, and Proxy/Reflect-based metaprogramming -- that turn engine-level understanding into maintainable, production-grade systems. This is the difference between writing JavaScript that happens to work and architecting JavaScript that holds up under scale, team growth, and time.