Watchers & Computed Properties

[00:00:00]
>> So the section we're gonna be kicking off right now is on watchers and computed properties. We've talked a lot about reactive data and we saw that it's cool that it tracks, but the next step to reactive data a lot of times comes to the point where it's a question of what happens when things depend on that data, right?

[00:00:19]
So you want something to happen when the reactive data changes, this is actually fairly common. So granted we're doing a lot of things automatically at this point, right, so for example, when the data updates view will automatically update the HTML, but what do we wanna do more fine grained things.

[00:00:34]
So for example, we wanna say, we wanna watch the count up here, and if it's even, we want to go ahead and then say, update the title up here to something else, right? So you can imagine that if we had this to be counterTitle, for example. And counterTitle would just put it here.

[00:00:54]
So counterTitle is going to be, this is standard, for example, so we and refresh. Great, Counter Standard here. And we wanna say, we wanna watch for, if the count goes past 20, then we wanna add like long to the text. And so your first instinct for those who come from a framework background is to think, well, we need to be able to watch the thing, right?

[00:01:18]
And so to watch something in view is actually fairly simple. There actually is a watch option as you would expect. So you have data, we have methods, here's our opportunity to watch something. And when you wanna watch something, you basically say, what is it exactly that we're watching?

[00:01:33]
Well, in this case, we're watching the count. And so when you actually define the count though, what you wanna do is you wanna say you need the value that is basically going to return to you by default cuz otherwise you don't have something to refer to inside of that value.

[00:01:48]
Cuz it's gonna basically say, what your new value, what's your old value? And so by default, you get the new value as the first one so I'm actually just do a new value like this. So you'll see now, here we have a simple watch function that's watching count.

[00:02:01]
And then when it changes, we should automatically see it log. And so watch count, they're now refresh. Refreshing would be helpful. There we go, okay. So we can see here 1826, we're getting some loss as well here from increment count, but we see that at least it's being triggered.

[00:02:21]
So your next thing would be like okay, well logically speaking, what I would wanna do then is I would say, well, if new value is greater than 20, then this dot counter title. Counter title plus equals very long, okay. Now, refresh 1, 2, you can see boom, it's updated.

[00:02:45]
And so from a mental model perspective, you're like, yeah, that makes sense, cool. And so this is actually a common paradigm in a lot of frameworks when it comes to watching reactive dependencies. That's what it's called. But view has a better way for us to do this, especially when it comes to modifying existing data.

[00:03:01]
Because if you think about what we're doing here, what we're doing is we're saying based on a reactive data property, run a specific computation. And then, but we think about that from a performance perspective, we really only wanted to do that when all the dependencies, like the right dependencies are triggered.

[00:03:17]
And so one of the problems that comes with doing something as like explicitly watching values is sometimes especially when apps get really large. The watch can end up getting triggered a lot, like unnecessarily so. And so when you hear things about people accidentally triggering re renders, that's what they're talking about.

[00:03:35]
It's because at that point, you're manually watching the dependencies and if you don't know what you're doing, we're not cashing it correctly. All of a sudden you might be triggering re-rendering of thousands of nodes and wattnode. So view in its view version came up with an API that would help to abstract that away.

[00:03:52]
And the way it does that is through the idea of computer properties. Nice so the way computer properties work is basically another option on your app. So I'm gonna add it below data because and you'll see shortly why. So computer properties is, think of it as basically performance optimized calculations on reactive data that you have.

[00:04:15]
So in the instance of, for example, the counter title, right? Rather than it be like okay, well, I'm gonna have a watch on this count, if it's 20, then add the thing. Instead, you could be, I'll say, display title for example. And so this will be a function that view will basically, it will correctly decide when to run it.

[00:04:37]
So we'll see shortly. And in this function, what are we gonna do? We're gonna say, if this.count is greater than 20, return counter standard. Otherwise return, wait. In this case it was counter very long. Otherwise, return counter standard, just like that. And so if we switch this over now to do, do, do, do display title.

[00:05:07]
And refresh. You see nothing changes, and then it's swapped and then it's good. And basically, even though you might think programmatically, this looks very similar to what we just did. This is extremely powerful because what you've just done is now given view the job of figuring out when its dependencies have changed.

[00:05:26]
And so to show you what I mean by that we could even combine computed properties together. So for example, let's say that we actually wanted to impact the increment amount based on the length of the title. Let's just do that. So we could then say, see, as I call it, optimizedIncrementAmount.

[00:05:44]
And for whatever reason, we have some algorithm that's dependent on the counter title. What we could do instead, we can return this.countertitle or sorry, this.displayTitle.length times, and then let's say this incrementAmount. So now, we have two dependencies. We're depending on this displayTitle here, we're de depending on incrementAmount here.

[00:06:10]
But then, once we update here to optimize increment amount, we can see now that things are starting to change actually pretty drastically, right? You're seeing that the actually, I've realized you're not actually seeing the optimized amount. So let's show that real quick. Where's my incrementCount, okay. Here we go.

[00:06:30]
Then we can say optimizedIncrementAmount. Very good. So you see here's 224 right here. And so it's changing because, why? Because we've modified the title. If we modify this times 10, you'll see that now it's updating correctly by the incrementAmount, but the optimize amount is not dependent on two different things.

[00:06:52]
And so what you get with computer properties is basically really efficient tool chaining on reactive dependencies. And this is a concept we're starting to see popularized, I think spelt has something very similar as well now. In that, if you think about an enterprise level app, there's going to be so much that's changing.

[00:07:09]
And when you have manual definitions of what you're watching, oftentimes you'll find that it's actually fairly brittle, because one small change will break that entire dependency chain. Whereas here, you can have your source of truth being this data store, and then you can have all your computations run off of that thing.

[00:07:26]
Right, and it knows when to trigger, it knows what to do, it knows how to cache it so that in the HTML, it doesn't randomly trigger like, all that stuff that our goal is to build cool things and to abstract business logic deliver value to customers. As much as it's fun to learn about performance optimizations, that's not something we want to be debugging constantly.

[00:07:44]
And so computed properties are incredibly powerful for this. In fact, if I were to say my single most favorite feature of view, it's the computed property cuz it just takes away all the worry for me about what's happening. And it does so much work for me again, really easy.

[00:08:00]
And it's particularly powerful if you do any data visualizations you can imagine, right? You're doing all these SVG calculations based on a set group of data. You don't wanna have to write the dependency chain that would update the SVG at this particular point, and then it swaps this way, or how it animates, all of that can be managed basically with computed properties.

[00:08:18]
And so some of the most elegant stores I've seen have one source of truth inside of data, and then they compute everything else out. And it works really, really well because view can optimize all those things.