Hey, everyone. In this video we're going to talk about the Meteor Deps package. The Deps package has changed a bit since the last time I did a video on it. So I thought it was time to revisit. The Deps package is a pretty core part of how Meteor works. And essentially what it does is it allows us to re-run one or more functions if a dependent data source changes.
So in this video, we're going to talk about the Deps autorun method and the flush method and look at a few examples. In the next video or two, we'll look at a computation, the Deps.computation, Deps.dependency. And then maybe in that video, or one that's on its own, we'll look at an actual example of using Deps to do some custom reactivity.
OK, let's get started. I've created some boilerplate client side code on the left hand side. I have two functions-- an updateName function that just sets a session variable called name equal to my name plus an incrementing counter. And then I have another function called printName that just prints the current session, the value of calling Session.get with the name key and prints that to the console. And you'll notice that I've made all of these functions global variables so that we can play with them in the console.
And so just to convince you that it works, let's go over to the browser. And if I type printName, it's currently set to-- well, it should be undefined. Let me restart here. OK, so now it's undefined. But if I call the updateName method and then say printName again, it gets set to the Chris plus the counter, which has been incremented by one.
And so what we want to accomplish here with Deps is we want to say any time the name changes, I want to run this function again. So to accomplish this, we can use the Deps.autorun function. That function takes a callback function as a parameter. And that callback function gets a computation when it gets called. And we'll talk about computations in another video.
Now, inside this autorun callback, if I call the printName method, what will happen here is because printName depends on Session.get name, which is a reactive data source, any time that value changes, the printName function will be re-run again. And so you can see already over on the right hand side that we run the printName name function once, and the name is currently undefined because we haven't set it.
But if I say updateName, the printName function gets re-run. And if I say updateName again, it gets re-run again, and so on. And so that's what Deps.autorun gives us. It allows us to re-run a function when that function's data dependencies change.
So just to save a little bit of space, I can also just pass a function to this. So I'll just pass the printName function as a parameter. And one of the cool things about Deps is that I can have multiple functions that depend on the same data source and make each one of those functions reactive within an autorun callback. So let's just create another function called printName again. And what it's going to do is print the same thing. But I'm just going to put a 2 here so we can see the difference and a 1 here.
And then down here, I'm going to call Deps.autorun again. And this time I'm just going to pass it the printNameAgain function. OK, so now over in the right, you can see that every time the name is updated, both of these functions get re-run again. So let's call updateNameAgain. And we can see that both of our functions are re-run.
So one confusing part of this is you might ask, when exactly are the functions re-run? So when we call the updateName method up here, and we call Session.set, that's when the value changes to Chris plus the incremented counter. But these printName functions won't actually get called as soon as this happens.
The first thing that will happen is all of the code within this function will execute. And the system will then become idle. And when it becomes idle, Meteor does something called a flush. And during the flush is when all of the dependent functions get run again.
So that's a little bit confusing when you're reading the documentation. So let's illustrate it with an example. Let's put some more code underneath the Session.set line and updateName. I'm going to print to the console here that we're after the Session.set name so that we can see what happens. And then let's come over to the browser and just clear it and call updateName.
Now what you might expect is that as soon as I change the value of the name session key, that these two functions get run right away. But that's not what happens. You can see over on the right that this entire piece of code executes first. And so that's why we see over here that this string gets printed to the console first. And then after this method has returned, the other two functions get run.
So one of the things we can do is we can force all of the dependencies to be re-run by calling the Deps.flush method. So if we want to force the dependent functions to run right away, what we can do is called Deps.flush. And if I go over to the browser, I'm just going to refresh it so that we can refresh the session. And we see that the two functions are initially run right away.
And then if I call updateName, this time we see that the two functions are run first. And then we print to the console after the Session.set name. And that's because by calling Deps.flush, we force all of the dependent functions to run right away, as opposed to waiting for this entire code block to finish or for the system to become idle.
So in this introductory video, the key takeaway is that Deps.autorun allows us to run a function and then re-run that function if any of its dependent data sources change so long as those dependent data sources are reactive. And so a reactive data source example is Session. Another one is a cursor that gets returned when you call find on a collection. But we can also implement our own reactive data sources. And we'll do that in another video.