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 <mark>Observer</mark> pattern. It is a powerful pattern. It says that there is a <mark>subject</mark> - a particular object encloses some data, and there are <mark>observers</mark> - objects that want to know when that data changes and what value it has now.
How will they know about the change? The <mark>subject</mark> should tell them that he is changed. For that, every <mark>observer</mark> should ask the <mark>subject</mark> to notify it when something happens. It is a <mark>subscription</mark>.
And when some data changes, the subject notifies all known observers about that. That is a <mark>notification</mark>.
Pretty simple, yeah?
Practically, there are many implementations for this pattern. We are going to show the simplest one.
Proxy is a wrapper around the object which can intercept and redefine fundamental operations for that object (MDN resource).
By default, <mark>Proxy</mark> 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.
With this ability, we can write our initial <mark>store</mark> function. In the end, we should be able to do this:
As I said earlier, the <mark>subject</mark> (our object with some data) should notify <mark>observers</mark> (some entities) when its data was changed. That can be made only when the <mark>subject</mark> knows what entities want to receive notifications. That means that the <mark>subject</mark> should have a list of <mark>observers</mark> inside.
And now, we should define a trap for assigning a new value to the target object. That behaviour defines a <mark>set</mark> interceptor.
After updating the value, the <mark>subject</mark> notifies all <mark>observers</mark> that were added to the list of observers. Great! We've created a notification behaviour. But how does the <mark>subject</mark> add an <mark>observer</mark> to the subscription list?
The answer is that the <mark>subject</mark> should expose a way to trigger this subscription. With <mark>Proxy</mark> 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 <mark>Proxy</mark> 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 <mark>get</mark> interceptor and provide a handler for an absent property. At the same time, we shouldn't block access to the target's properties.
You may notice that the execution of the <mark>subscribe</mark> function returns another function. Yes, indeed. Observers should be able to stop listening to changes when they want to. That's why <mark>subscribe</mark> 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 <mark>delete</mark> interceptor is for that.
And now our <mark>store</mark> 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 <mark>store.js</mark> 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!