DEV Community: joel.

The Observer Pattern

joel. — Fri, 22 Mar 2019 15:43:54 +0000

The Observer Pattern is a design pattern in software engineering that allows communication between multiple places. In web development it can be a way to communicate complex changes to data, and to separate UI from business logic. But before we go into how you can start using this pattern, let's go over some real world examples to make sure we understand what it is.

Let's say you find out about a new magazine that releases new issues every month. You want to keep up with all the new issues right when they come out. So you subscribe to the magazine and then every month when a new issue is released it shows up at your door. Great, right? Eventually you might get bored of the content, or you get sick of paying for it every month, so you unsubscribe from it. Then, the next time an issue is released it doesn't show up at your door.

This is a real world example of the observer pattern. Whether you've known it or not, you probably run into this every single day. Things like email newsletters, RSS feeds or subscribing to tweets from your friends are other examples.

The Observer Pattern

There are two components to the observer pattern. The subject and the observer. Each subject can have many observers. When an observer subscribers to the subject, it will be informed when changes happen to the subject. The diagram below gives a quick overview of the structure, but we'll dig deeper in just a second.

The Subject

Look at the subject as the thing that's going to be observed. Every subject needs a method to subscribe and a method to unsubscribe. Internally this just adds and removes a function from an array.

Once subscribing and unsubscribing from the subject has been setup, any time you want to inform subscribers of something, you just have to iterate over each if them and pass them the data they should know about.

So depending on what the subject is, you might provide a method for others to update some local state, and every time that local state is updated you let all the subscribers know by passing them the updated state.

Or maybe the subject periodically fetches new data from am API and any time the data changes it lets subscribers know.

The possibilities are endless as long as you include a way to subscribe and unsubscribe, and make calls to each subscriber whenever something important happens.

Here's an example of a super basic implementation of an observer subject.

class Subject {
  subscribers = []

  subscribe = (functionToSubscribe) => {
    this.subscribers.push(functionToSubscribe)
  }

  unsubscribe = (functionToUnsubscribe) => {
    this.subscribers = this.subscribers
      .filter(func => func !== functionToUnsubscribe)
  }

  action = (data) => {
    this.subscribers
      .forEach(subscriber => subscriber(data))
  }
}

The Observer

Once the subject is all setup and ready to accept subscribers, you just have to pass a function to the subscribe method to get started. This function you pass to subscribe is called an observer. You can have lots of observers watching a single subject. Observers can be added and removed whenever they want. An observer should expect some sort of data to be passed in related to the subject and should perform some sort of action because of it.

// Create a new subject to observe.
const subject = new Subject()

// Create a new function and subscribe to the subject.
const observerFunction = (data) => console.log(data)
subject.subscribe(observerFunction)

// Stuff happens with subject
subject.action('foo')
subject.action('bar')

subject.unsubscribe(observerFunction)

// More stuff happens, but the `observerFunction` will never find out.
subject.action('baz')

Examples

Now that we know all the components of the Observer pattern, let's take a look at a few examples.

Counter

In this example the subject is a counter. It provides methods to subscribe, unsubscribe, and add to the count. Any time you click the +1 or -1 buttons the count will change.

There are then three observers that store and display the last count they are informed of. Initially none are observing the count, but you can toggle this by pressing the subscribe/unsubscribe button.

Play around with it for a while, change subscriptions and change the count to see which ones update and which ones don't and when.

Toasts

While the counter is fun to play with and gives a good visual of how the observer pattern works, it's not super practical. Toasts, on the other hand, are a bit more practical and are a much more real-world example of when this pattern is useful.

If you've never heard the term "toast" before, it's a notification that pops up (you know, like toast out of a toaster) briefly when you're on a site. Usually it's used to provide feedback after the results come back from some previous action you performed.

So in our example, our subject is toasts, and our observer is the UI that will display new toasts as they are received. So the toasts subject has methods to subscribe and unsubscribe from new toasts, and it also has methods for creating success toasts, warning toasts, and error toasts.

Each time the success, warning, and error methods are called, the new toasts are sent to the subscribers. When our observer receives a new toast, it briefly renders it.

By implementing our toasts in this way, we can have one subject and one observer and call the success, warning, and error methods from anywhere in our codebase to display a toast. This is really useful in providing a generic tool the rest of our codebase can use to render a toast while keeping the UI logic out of the business logic that needs to trigger it.

That's It!

Pretty simple, right? Now you're an expert on the observer pattern. This article is part of an ongoing series on web development design patterns, so now go check out the others or come back later for more.

How to Limit Dependency on 3rd Party Tools and Libraries

joel. — Wed, 02 Jan 2019 22:27:04 +0000

NPM and other package managers have made integrating 3rd party libraries easier than ever.

Need to build a UI? There's a package for that.

Need to format time? There's a package for that.

Need to add authentication? There's a package for that.

Nowadays there's open sourced code that does practically everything. Just npm install it and you're on your way. Simple enough, right?

But what happens when that package you installed stops being maintained or you find out has a security vulnerability? What do you do when a newer, faster, and smaller package is released?

It's easy to allow 3rd party code to weave and integrate itself into your app, and it's only until you need to replace or remove it that you realize it's become more of a weed than a benefit.

Refactoring and changing libraries is eventually inevitable in practically any long term project. So what can you do to make the migration process easier?

Reducing Dependency

In order to reduce dependency on a 3rd party library, you can create a single entry point where the 3rd party library is accessed. Then, throughout the app, you can access the local entry point instead of accessing the package directly. The day you decide to migrate, all you have to do is migrate the entry point instead of every instance the package was used.

Wrapping 3rd party libraries in this manner also makes it easier for you to add or modify functionality if something needs to be adjusted.

If the newer library has a different API, or if you just aren't a fan of the API to begin with, this gives you the opportunity to create your own custom API while reaping all the rewards of using an existing library.

An Example

Let's say there's a package we want to add called text-upper that capitalizes text.

Instead of accessing the package directly, first we create an entry point in say utils/caseChanger. Usually it's better to name it something generic or descriptive instead of just naming the entry point the same as the package.

Inside the entry point can be something as simple as:


import TextUpper from 'text-upper'

export default TextUpper

Then anytime we need to upper case text we just access the library through our entry point like so:

import caseChanger from './utils/caseChanger'

upperCase.makeUpperCase('hello world')

Later on, we find an even better package called textMcChanger that not only makes text uppercase, but also makes text lower case too. We definitely want that.

So now all we have to do is modify our entry point to use this new package. And even though the new package has a slightly different API for capitalizing text, we only have to modify our entry point to ensure everywhere we're already capitalizing text doesn't also need to be refactored.

Our migration in the utils/caseChanger might end up looking something like this:

import betterPackage from 'textMcChanger'

// Modify API for backwards compatibility
betterPackage.makeUpperCase = text => betterPackage.upper(text, true)

// Modify API for consistency with old API
betterPackage.makeLowerCase = text => betterPackage.lower(text, true)

export default betterPackage

Easy enough, right? All we had to do was change this one file and our app instantly reaps the benefits of the new package without requiring all the extra refactor.

Conclusion

Obviously it won't make sense to wrap every package like this. It would be silly to try to add a wrapper for React as your UI library and then later try to transform Vue to work like React. But I guess you could!

For most other things though, it's a good practice to follow, and you'll thank yourself later once you find the perfect replacement and you don't have to dread the migration.