How to write a super simple reactive state manager

Every application needs a state management system to have the ability to react to changes in the data. There are lots of state managers for every taste, from easy to understand ones to mind-breaking.

Do you know how they work? What principles stand behind them? I'm sure you are. But these questions I asked myself not a long time ago, and in my opinion, it is still unknown territory for beginners. So, shall we go in?

Behind most managers stands the Observer pattern. It is a powerful pattern. It says that there is a subject - a particular object encloses some data, and there are observers - objects that want to know when that data changes and what value it has now.

How will they know about the change? The subject should tell them that he is changed. For that, every observer should ask the subject to notify it when something happens. It is a subscription.

And when some data changes, the subject notifies all known observers about that. That is a notification.

Pretty simple, yeah?

Practically, there are many implementations for this pattern. We are going to show the simplest one.

Basically, the data of your application aggregates into a restricted scope. In JavaScript, we can use an object for that purpose. Each key represents a separated independent chunk of the data.

const state = {
    key1: "some useful data",
    key2: "other useful data",
    // and so on
}

We can freely read and change these chunks as we want. But the problem is that we cannot predict when the change happens and what piece is changed with what value. Simply put, the object isn't reactive. Fortunately, JavaScript has a feature that helps us track any action that is made with any object. Its name is Proxy.

Proxy is a wrapper around the object which can intercept and redefine fundamental operations for that object (MDN resource).

By default, Proxy passes through all operations to the target object. To intercept them, you need to define traps. A trap is a function whose responsibility is to redefine some operation.

All operations and their trap names you can find [here].(https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy/Proxy#handler_functions)

With this ability, we can write our initial store function. In the end, we should be able to do this:

const appState = store({ data: 'value' });

// Subscribe to the data changes.
appState.on('data', (newValue) => {
    // do something with a newValue
});

// Somewhere in the code
appState.data = 'updated value'; // observer is invoked

As I said earlier, the subject (our object with some data) should notify observers (some entities) when its data was changed. That can be made only when the subject knows what entities want to receive notifications. That means that the subject should have a list of observers inside.

const store = (target) => {
    const observers = [];

    return new Proxy(target, {});
}

And now, we should define a trap for assigning a new value to the target object. That behaviour defines a set interceptor.

const store = (target) => {
    const observers = [];

    return new Proxy(target, {
        set: (target, property, value) => {
            target[property] = value;
            observers
                .filter(({ key }) => key === property)
                .forEach(({ observer }) => observer(value));
            return true;
        },
    });
}

After updating the value, the subject notifies all observers that were added to the list of observers. Great! We've created a notification behaviour. But how does the subject add an observer to the subscription list?

The answer is that the subject should expose a way to trigger this subscription. With Proxy in mind, we can define a virtual method that will accomplish that process. How can we do that?

Virtual method is a method that doesn't exist in the target object, but Proxy emulates it by creating it outside of the target object.

As we know, a method is a property which value is a function. That tells us that we should define a get interceptor and provide a handler for an absent property. At the same time, we shouldn't block access to the target's properties.

const store = (target) => {
    const observers = [];

    return new Proxy(target, {
        get: (target, property) => 
            property === 'subscribe'
                ? (key, observer) => {
                      const index = observers.push({ key, observer });
                      return () => (observers[index] = undefined);
                  }
                : target[property],
        set: (target, property, value) => {
            target[property] = value;
            observers
                .filter(({ key }) => key === property)
                .forEach(({ observer }) => observer(value));
            return true;
        },
    });
}

You may notice that the execution of the subscribe function returns another function. Yes, indeed. Observers should be able to stop listening to changes when they want to. That's why subscribe returns a function that will delete the listener.

And that's it! We may want to make deleting a property reactive. As we did earlier, a delete interceptor is for that.

const store = (target) => {
    const observers = [];

    return new Proxy(target, {
        get: (target, property) => 
            property === 'subscribe'
                ? (key, observer) => {
                      const index = observers.push({ key, observer });
                      return () => (observers[index] = undefined);
                  }
                : target[property],
        set: (target, property, value) => {
            target[property] = value;
            observers
                .filter(({ key }) => key === property)
                .forEach(({ observer }) => observer(value));
            return true;
        },
        deleteProperty: (target, property) => {
            delete target[property];
            observers
                .filter(({ key }) => key === property)
                .forEach(({ observer }) => observer(undefined));
            return true;
        },
    });
}

And now our store function is complete. There are a lot of places for improvements and enhancements. And it is up to you! 🤗

Also, you can see a slightly better implementation in our @halo/store package. A code from these examples lives in the store.js file. But there is one more entity that is worth explaining. That's why we plan to write the next article precisely about it where we are going to explain the purpose of the package and in what situations you may need it. Hold tight and cheer up!

Supported by Halo Lab design-driven development agency