Capstone Integration Patterns

In our previous lessons, we explored powerful meta-programming tools in isolation. We saw how the Proxy object and Reflect API allow us to intercept and change how objects behave. We also learned how Tagged Template Literals can turn simple strings into specialized tools like secure SQL query builders. While these tools are impressive on their own, their true power is unlocked when we combine them to build a cohesive system.

In this final lesson, we are going to build a Capstone project that integrates everything we have learned. To do this, we need an architectural spine to hold all these pieces together. We will use the Observable pattern. This pattern allows different parts of our application to stay in sync without being directly connected to one another. By the end of this lesson, you will understand how to design objects that are not just data containers, but smart entities that broadcast changes, support custom protocols, and work seamlessly with functional programming helpers.

On the CodeSignal IDE, you will find all the modern JavaScript features we use are ready to go. While you can use these patterns in any environment, here you can focus entirely on the logic of the integration. Let's begin by looking at the core of our system: the Observable.

The Observable pattern, also known as publish/subscribe, is a design where an object maintains a list of listeners and notifies them automatically of any state changes. This is a vital pattern in modern software because it allows us to keep our code decoupled. This means the object sending the update doesn't need to know who is listening or what they will do with the information.

To implement this safely, we use a private #subscribers Set. Using a Set ensures that the same listener function cannot be added twice. The subscribe method first validates that the argument is a function, throwing a TypeError if it is not. This prevents subtle bugs that would otherwise surface only at notification time. When validation passes, we return an unsubscribe closure. This is a small function that remembers the listener and the Set, allowing the user to stop receiving updates by simply calling that returned function. This approach is much cleaner than exposing the internal list of listeners to the outside world, as it protects our data from being accidentally changed by other parts of the program.

When it comes time to send an update, the notify method iterates over a copy of the subscribers. We create this copy using the spread operator [...this.#subscribers]. This is a defensive programming technique. If a listener tries to unsubscribe right in the middle of receiving a notification, iterating over a copy prevents our loop from breaking or skipping other listeners. Each listener call is also wrapped in a try/catch block. This ensures that if one listener throws an error, the remaining listeners still receive the notification. The error is logged to the console so it is not silently swallowed.

class Observable {
  #subscribers = new Set();

  subscribe(fn) {
    if (typeof fn !== "function") throw new TypeError("Subscriber must be a function");
    this.#subscribers.add(fn);
    return () => this.#subscribers.delete(fn);
  }

  notify(event) {
    for (const fn of [...this.#subscribers]) {
      try { fn(event); } catch (e) { console.error("Listener error:", e); }
    }
  }
}

const bus = new Observable();
const received = [];
const off = bus.subscribe((e) => received.push(e));

bus.notify("hello");
off();
bus.notify("ignored");

console.log("received:", received);

In the output below, you can see that only the first message was saved because we used the off switch returned by the subscribe method before the second message was sent.

received: ["hello"]

Now that we have our core Observable class, we can use it to build a real-world Domain Class. In software design, a domain class represents a specific concept in your business, like a User or a Bank Account. By having our Account class extend Observable, we give it the ability to broadcast its own life events, such as deposits or withdrawals.

The Account class uses private fields like #balance to ensure that money cannot be changed from the outside without going through our official methods. When the deposit or withdraw methods are called, they update the balance and then call this.notify(). This sends an object containing the event type and the new balance to any interested listeners. This pattern makes the Account reactive; for example, a logging tool or a user interface could listen to these events and update themselves automatically without the Account class needing to know they exist.

We also use a custom DomainError class here. This is a helpful practice for integration patterns because it allows us to attach specific error codes to our failures. If a user tries to withdraw more than they have, we throw an error that includes a code like E_FUNDS, making it easier for other parts of the system to decide how to handle the mistake.

For brevity, this Account omits input validation: it does not reject negative deposits, negative withdrawals, or non-finite numbers. A real domain model would validate every mutation (for example, requiring a positive, finite amount). We leave that out here to keep the focus on the integration pattern.

class DomainError extends Error {
  constructor(message, code) {
    super(message);
    this.name = "DomainError";
    this.code = code;
  }
}

class Account extends Observable {
  #balance;
  constructor(owner, balance = 0) {
    super();
    this.owner = owner;
    this.#balance = balance;
  }

  deposit(n) {
    this.#balance += n;
    this.notify({ kind: "deposit", amount: n, balance: this.#balance });
    return this;
  }

  withdraw(n) {
    if (n > this.#balance) throw new DomainError("Insufficient funds", "E_FUNDS");
    this.#balance -= n;
    this.notify({ kind: "withdraw", amount: n, balance: this.#balance });
    return this;
  }
}

In JavaScript, we can use Symbols to define how our objects interact with the language's built-in features. These are often called Protocols. By implementing specific Symbol methods, we can make our custom Account class behave like a native data type. This makes our objects much more intuitive for other developers to use.

The first protocol we implement is Symbol.iterator. By adding a generator function with this name, we make our object iterable. This means we can use the Account object in a for...of loop or use the spread operator [...] to turn it into an array of key-value pairs. This is much more flexible than just looking at property names.

The second protocol is Symbol.toPrimitive. This method tells JavaScript how to convert our object into a simple value like a string or a number. When JavaScript asks for a number, we return the balance. When it asks for a string, we return a formatted label. Finally, we use Symbol.toStringTag to change the default description of the object. Instead of the generic [object Object], it will now show [object Account].

class Account extends Observable {
  // ... (previous constructor and methods)

  *[Symbol.iterator]() {
    yield ["owner", this.owner];
    yield ["balance", this.#balance];
  }

  [Symbol.toPrimitive](hint) {
    return hint === "number" ? this.#balance : `Account<${this.owner}>`;
  }

  get [Symbol.toStringTag]() {
    return "Account";
  }
}

const acc = new Account("Ada", 100);
console.log(`${acc}`);
console.log(+acc);
console.log(Object.prototype.toString.call(acc));

The output demonstrates how the object now responds intelligently to different contexts based on the implementation of these protocols.

Account<Ada>
100
[object Account]

As we integrate these different parts, we often need small utility functions to help transform data. These are called functional combinators. They are higher-order functions, meaning they take functions as inputs and return new functions as outputs. Using these allows us to write code that is very readable and easy to test.

The pipe function is used to chain multiple operations together in a sequence. Instead of nesting functions inside each other, which can be hard to read, pipe lets us list them in the order they happen. The curry function allows us to provide arguments to a function one at a time. This is useful for creating specialized versions of a general function. Finally, the memoize function creates a cache for another function. If we call a memoized function with the same input twice, it will return the cached result instead of doing the work again, which is a great way to improve performance for expensive calculations.

These tools represent a different style of meta-programming. Instead of intercepting object properties, we are wrapping and modifying the behavior of logic itself. In our integrated system, these helpers are often used to process the events coming out of our Observable objects or to format the data being retrieved through our Symbol protocols.

const pipe = (...fns) => (x) => fns.reduce((acc, f) => f(acc), x);

const curry = (fn) => {
  const c = (...args) => args.length >= fn.length ? fn(...args) : (...rest) => c(...args, ...rest);
  return c;
};

const memoize = (fn) => {
  const cache = new Map();
  return (...args) => {
    const key = JSON.stringify(args);
    if (!cache.has(key)) cache.set(key, fn(...args));
    return cache.get(key);
  };
};

const add = curry((a, b, c) => a + b + c);
console.log("curry:", add(1)(2)(3));

const result = pipe((n) => n + 1, (n) => n * 2)(10);
console.log("pipe:", result);

Caveat: our memoize builds its cache key with JSON.stringify(args). That is fine for simple serializable arguments, but it breaks down for circular objects, functions, symbols, undefined, and objects whose keys appear in different orders. A production memoizer typically accepts a custom keyFn so the caller controls how arguments map to cache keys.

Now we can see all these pieces working together in a single system. Our Account class is the star of the show. It manages its private state and notifies its subscribers whenever a change occurs. Simultaneously, it uses the sql tagged template we explored in Lesson 3 to format a query string. (Recall that this quote-doubling is only a formatting demonstration; for real injection safety a production app would use the parameterized { text, params } approach from Lesson 3.)

We also bring back the concept of Reactivity from Lesson 2. By using a Proxy, we can create a reactive state object that automatically logs changes to the console. This shows that we can use different layers of meta-programming at once: the Account handles business events through the Observable pattern, while a Proxy handles generic state updates. We also use a WeakMap to store extra metadata about our objects, like a created at timestamp, without cluttering the actual class definition.

Before we run everything, here is a map of how the pieces relate:

        subscribe(fn) ─────────────┐
                                    ▼
   ┌───────────────┐  notify(event)   ┌─────────────┐
   │   Account     │ ───────────────▶ │  listeners  │  (Set of callbacks)
   │ (Observable)  │                  └─────────────┘
   │   #balance    │
   └──────┬────────┘
          │ described by
          ▼
   ┌───────────────┐      ┌────────────────────────┐
   │   WeakMap     │      │ createReactive (Proxy)  │ ── onChange ─▶ console
   │   metadata    │      │  generic state object   │
   └───────────────┘      └────────────────────────┘

In words: an Account is an Observable, so calling its methods publishes events to a Set of listeners. A WeakMap holds side metadata about each account without touching the class. A separate Proxy from createReactive watches a plain state object and logs changes.

We will assemble this in three checkpoints: (1) the domain layer (Observable + Account + Symbol protocols), (2) the functional/utility layer (pipe, memoize, sql, lazy generators), and (3) the meta layer (reactive Proxy, WeakMap). Keeping these three layers separate in your mind is the key to not getting lost.

By combining Symbols for language protocols, Proxies for reactivity, and the Observable pattern for event-driven architecture, we create a system that is both powerful and easy to extend. Some of these patterns appear in modern libraries and frameworks — for example, Vue uses proxy-based reactivity, and database drivers commonly expose parameterized query objects — though each tool combines them differently. All these tools are standard in modern JavaScript and are fully supported in the CodeSignal environment.

(async () => {
  const acc = new Account("Ada", 100);
  const events = [];
  const unsub = acc.subscribe((e) => events.push(e));

  acc.deposit(50).withdraw(30);
  unsub();

  console.log("Events:", events);
  
  const owner = "O'Brien";
  const query = sql`SELECT * FROM accounts WHERE owner = ${owner}`;
  console.log("Query:", query);
})();

In the output, you can see the event stream captured by the Observable and the formatted SQL string generated by the sql tagged template.

Events: [
  { kind: 'deposit', amount: 50, balance: 150 },
  { kind: 'withdraw', amount: 30, balance: 120 }
]
Query: SELECT * FROM accounts WHERE owner = 'O''Brien'

Congratulations on reaching the end of the Meta-Programming and Advanced Integration Patterns course! We have traveled from the low-level details of property interception with Proxies and Reflect, through the creation of custom languages with Tagged Templates, and finally to building an integrated system using the Observable pattern and Symbol protocols.

You now have a robust toolkit for writing code that manages code. You understand how to make objects reactive, how to protect your data with private fields and snapshots, and how to make your custom classes feel like native parts of the JavaScript language. Some of these patterns appear in modern libraries and frameworks — for example, Vue uses proxy-based reactivity, and database drivers commonly expose parameterized query objects — though each tool combines them differently.

In your final practice exercises, you will put all these skills to the test. You will build a system that combines event-driven logic with functional helpers and custom protocols. Take your time to review how each piece fits together. Understanding the relationship between these advanced features is what separates a standard developer from a meta-programming expert. Good luck with your final exercises!