JS Observer Pattern

JS Observer Pattern

Notify subscribers automatically when an observable object's state changes

When to Use

• Multiple parts of the app need to react to the same event without coupling the emitter to its consumers
• Implementing event systems, reactive UI updates, or real-time data feeds
• Decoupling data sources from their consumers

Instructions

1. Create an observable with an observers array and subscribe / unsubscribe / notify methods.
2. Call notify(data) whenever the observable's state changes — it invokes all subscribed callbacks.
3. Always provide unsubscribe — failing to unsubscribe causes memory leaks in long-lived apps.
4. In browser environments, prefer native EventTarget or EventEmitter (Node.js) over hand-rolled implementations.

class Observable {
  constructor() {
    this.observers = [];
  }

  subscribe(fn) {
    this.observers.push(fn);
    return () => this.unsubscribe(fn); // return cleanup function
  }

  unsubscribe(fn) {
    this.observers = this.observers.filter((obs) => obs !== fn);
  }

  notify(data) {
    this.observers.forEach((fn) => fn(data));
  }
}

const store = new Observable();
const cleanup = store.subscribe((data) => console.log('Received:', data));
store.notify({ type: 'UPDATE', payload: 42 });
cleanup(); // unsubscribe

5. Return a cleanup/unsubscribe function from subscribe — consumers call it to remove the handler.

Details

The Observer pattern (also called pub/sub) separates the emitter (subject/observable) from its consumers (observers/subscribers). This decoupling is fundamental to event-driven architectures, reactive state systems, and streams.

Trade-offs:

• If observers are not unsubscribed, the observable holds references to them — memory leak risk in SPAs
• Cascade updates — one observable notifying many observers can cause complex update chains that are hard to trace
• No guaranteed delivery order unless explicitly enforced
• Debugging is harder than direct calls — add logging in notify() during development

When NOT to use:

• When only one consumer exists — a direct callback is simpler
• When the update sequence matters and subscribers need to be ordered — use a queue or middleware chain instead
• For synchronous, predictable data flow — use signals or reducers

Source

https://patterns.dev/javascript/observer-pattern

Process

1. Read the instructions and examples in this document.
2. Apply the patterns to your implementation, adapting to your specific context.
3. Verify your implementation against the details and edge cases listed above.

Harness Integration

• Type: knowledge — this skill is a reference document, not a procedural workflow.
• No tools or state — consumed as context by other skills and agents.

Success Criteria

• The patterns described in this document are applied correctly in the implementation.
• Edge cases and anti-patterns listed in this document are avoided.