How to write a super simple reactive state manager
Tags: reactivity, javascript, webdev, proxy
Published: 2021-11-03 08:24:53

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`.

![Three observers subscribe to a target object](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/lifxdpt2uwowo7ofip8c.png)

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

![The target object notifies observers about its update](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5q8lo1yki2d894tv73ai.png) 

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.

```js
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](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy)).

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:

```js
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.

```js
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.

```js
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.

```js
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.

```js
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](https://github.com/Halo-Lab/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](https://www.halo-lab.com/) design-driven development agency_