Continuing our quest into trending design patterns for front-end developers, we follow up our first article on the Singleton pattern with a look at the Facade pattern in this second piece. Now we will dive into the observer pattern.

Observer pattern

The Observer pattern is an easy-to-understand, and widely used messaging design where an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes. This promotes a loose coupling between related objects and allows for efficient communication between them.

Real case scenario

Consider a Customer and a Store. The customer wants a new iPhone model not yet available in the store. They could check daily, but most trips would be unnecessary. Alternatively, the store could spam all customers whenever a new product arrives, saving him them from pointless trips but annoying others. This creates a dilemma: either the customer wastes time or the store wastes resources.

The observer pattern solution

In the example above, the Customer is the observer while the Store is the subject. The Customer may want to receive updates on a specific category of products, or not, giving it the possibility of choosing what it wants to observe.

In that case, the the Store (i.e., the subject) knows who is interested in its updates (the Customer, or observer), and there can be many Customers. Various Customers can sign up for updates from the same Store, and all will receive notifications whenever a new product is added.

This communication can occur every time a new product is created, updated, or removed in the Store.

Even though the Store knows who its Customers are in the Observer pattern, it doesn't concern itself with or know what each Customer will do with the updates received. Each Customer has complete control over what to do with the updates they receive.

Another pattern that looks really similar to the observer is the Publisher/Subscriber pattern, that I will cover on the next post of the series.

Code example

If you are like me, you want to see the code, it makes it simpler to understand, so here's a simple JavaScript code example illustrating the Observer pattern:

// Define a class for the Provider
class Store {
  constructor() {
    this.observers = [];
  }

  // Add an observer to the list
  add(observer) {
    this.observers.push(observer);
  }

  // Notify all observers about new product
  notify(product) {
    this.observers.forEach(observer => observer.update(product));
  }
}

// Define a class for the Observer
class Customer {
  update(product) {
    console.log(`New product added: ${product}`);
  }
}

// Usage
const store = new Store();
const customer = new Customer();
store.add(customer); // Add a customer to the store's observers
store.notify('iPhone 15'); // Notify all observers about a new product

In the code above, the Observer pattern is exemplified through the creation of two classes, Store and Customer.

The Store class represents the provider (some people may call it the subject). It has an array observers that stores all the observers (Customer instances) that are interested in updates from the Store. It also has an add method to add a new observer and a notify method to notify all the observers about a new product.

While the Customer class represents the observer, it has an update method that do some action when it receives the update, in this case it logs on the console.

All set, let’s use it. So we create aStore and a Customer object. The Customer is added to the Store's observers using the add method.

Then, the Store notifies all its observers (in this case, just one Customer) about a new product ('iPhone 15') using the notify method. The customer.update() method is called, and it logs the new product to the console.

That’s it! Now you have one more design pattern on your skill arsenal. Stay tuned for more exploration into different design patterns in this series, and let me know in the comments what design pattern you would like to see next!