Transcript
  • Meteor

Conclusion

From the class:  Tracker

Let's recap what we talked about in this class. We looked at how the tracker system works. And it starts with a function, so let's pretend we've got a function in our application. And then inside of that function, we make a reactive data source call. So for example, we might call session.get, and provide a key, provide a key here.

Now at some point previously in the call stack, a computation is most likely to have been set up by the framework or by some other code. And so a computation will be set. Let's change the color so it says if a computation could be set. So this is usually called the current computation. So by the time we get inside this function here, that computation has been set.

Now, the reactive data source called session stores a dependency. And that dependency stores array of all the computations in which the reacted data source is used, everywhere where this get function is called. Then later on, when we call this set function to change the reactive data source, and we set this key, for example, to some new value, we'll say 2, the reactive data source calls the changed method on the dependency, which loops through all of these computations and causes them to invalidate, which then reruns each of their respective function.

So it causes the function to rerun. And it does this all at once on the next tick of the event loop in something called a flush, where it drains an array of all the computations that need to be rerun.

So I hope this class gave you some good intuition about how the tracker or reactivity system works in Meteor, and gives you a bunch of useful tools. I gave you a bunch of useful tools for debugging this is kind of stuff in your app, or maybe even building a package that uses the reactivity system itself.