In vuejs it is possible to create reactive objects, by default this is the case with the data object of a vuejs instance. When I make a change to a property of the data object that will trigger an update to the view that uses that data object. So then there is this binding between state and view where a change to the state object of a system will automatically update a view that renders that state.
One way of thinking about getters and setters is that they can be thought of as event handlers of sorts where each time a property of a object is accessed the getter function is called, and the value that is returned by the getter is what will be used for the value of that property.
Although this way of defining a getter might work okay I have come to prefer using the define property method of doing so. One reason why is that I can stick to a syntax that is more in line with now I am familiar with defining objects properties. However the real reason why is because there are additional features of the define property method that allow for me to make properties of an object that are private.
There is starting out by making a simple method that will just make one property of an object reactive. This is more or less the starting point of making this kind of system as getters and setters need to be set up on a per property basis. So here I have an example of such a method that will take an object as the first argument, followed by a key that I want to make reactive, and then a draw function that will fire each time the value of the property changes. For a default draw method I am just using the console.log method.
I am then testing this out by creating a simple data object that just has a count property with a value set to zero. I then pass this object to the make property reactive helper, and set that it is the count property that I want to make reactive. When I go to change the value of the count property the result is that the console log method fires with the passed values for the object, as well as the key name in this case count, and the new value for the count key.
Now that I have a decent helper method for making a property reactive the process of making a full object reactive would just involve calling that helper for each key that I want to make reactive. One way to go about doing so for every public key of an object would be to use the Object.keys static method. There are many other options though such as a for in loop, or the Object.getOwnPropertyNames method that would come in handy of there are some private object keys that I would want to make reactive for some reason. However for this example I will just be using the object keys method and moving on with this one for now.
For this example I will be starting out with something that is not yet that advanced when it comes to making some kind of view and model binding type system. In this example I am using the define property object static method to create a hidden locals property for the object. This locals property will contain an object which is where I will actually store values that are set to the object using the assignment operator.
So this kind of trick is often used in many frameworks as a way to keep developers from having to update a model, and then do the same for a view thus having to update to things each time. Such a thing can often get messy, and confusing, so things like reactive objects can help to make it so I just have to update the model object, and by doing so that will trigger updating the view each time.
There is more to write about when it comes to the define property Object static method. Yet another interesting feature that has been added to the Object in the from of a static method is the Object.freeze method. However I tend to prefer using the define property method in place of it as that define property method has the ability to make it so a property of an object is not writable.
I do get around to editing my content now and then and with that said this is yet another post that I might want to put a little more time into at some point in the future. I can not say I have any plans to make my own relative object based framework of any kind in the near or distance future. WHen it comes to such frameworks I have to say that I really like to just use vuejs when it comes to that sort of thing. So with that said there is not much reason to bother, apart from making a very simple such module purely for the sake of this post. I might have to start that at least next time I come around to editing this post.