paint-brush
Nested Changes in Vue: How to Watch Out for themby@smpnjn
373 reads
373 reads

Nested Changes in Vue: How to Watch Out for them

by Johnny SimpsonMay 9th, 2022
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Nowadays, we have too many “testing tools” for every situation of development. Free or paid, inferior quality tools are like arrogant caddies on a difficult golf course. I will show you how to pick the good ones and ignore the bad ones by using a golf analogy. So, let’s play now.
featured image - Nested Changes in Vue: How to Watch Out for them
Johnny Simpson HackerNoon profile picture

Vue is a reactive language, meaning when the data changes, we can automatically have that represent itself in the HTML. To help us with this, we can use watchers in vue to watch for a change in data, and then do something to the HTML, or send a message to the user about it.

This works fine for simple datasets, but if we start to have data which is deeper than one level, it becomes harder to watch it properly for changes.

Watching for Nested Data Changes in Vue

To understand a little about this issue, we need to understand how watchers work in Vue. Vue only watches for shallow changes For example, below, we watch for changes in count, and console.log those changes:

<script>
export default {
    data() {
        return {
            count: 1
        }
    },
    watch: {
        count(data) {
            console.log(data);
        }
    }
}
</script>

<template>
    <h1>{{ count }}</h1>
    <button @click="++this.count">
        Click Me
    </button>
</template>


Every time the user clicks on the button, we ++this.count, and our watcher watches for any changes in count. It then console logs the data, so we can see the new count value. That means any time the button is clicked, the value of count is shown on the console log.


However, shallow changes means Vue only checks for changes in that properties value. If we have data more than one level deep, Vue will not check for updates. For example, updating count.number below will not trigger our watcher for count, since Vue simply doesn't check for any changes deeper than count:

data() {
    return {
        count: {
            number: 1,
            type: 'number'
        }
    },
    watch: {
        // This doesn't get triggered when count.number!
        count(data) {
            console.log(data);
        }
    }
}


Instead, we need to mention specifically which element is changing. We can continue to watch for changes in count.number above by changing our watcher to watch for count.number:

data() {
    return {
        count: {
            number: 1,
            type: 'number'
        }
    },
    watch: {
        // This gets triggered when count.number changes!
        "count.number" : function(data) {
            console.log(data);
        }
    }
}


Using the above method, we can easily check for changes in properties within properties, so that we can fire the appropriate watchers, but it can get messy. If we want to simply watch for any count changes, we need to use the deep property.

Using the deep property

The deep property can be added to any watcher, and it forces Vue to watch for any change within a specific data property. This means we have to write our watcher a little differently:


data() {
    return {
        count: {
            number: 1,
            type: 'number'
        }
    },
    watch: {
        count: {
            handler(data) {
                console.log(data);
            },
            deep: true
        }
    }
}


Now whenever any property within count changes, the count watcher will fire. When we console.log(data) this time, the entire count object will be console logged, i.e. { number: 1, type: 'number' }.


This is a lot easier than targeting specific properties within properties, but it is costly. Since Vue has to go through each property every time, this can cause serious performance issues for very large objects. As such, only use this if you have a known object of small size. For other situations, stick to targeting specific properties, like count.number.


Originally published here.