How does Meteor reactivity work behind the scenes?

Question

I read the docs and looked at the source of reactivity , but I do not understand this.

Can someone explain how this works behind the scenes, since to me it looks like magic :).

Answer 1

So, this is actually quite straightforward, at the basic level, 2 types of functions are involved:

• Functions that create a reactive context (reactive function)

• Functions that are not valid for a reactive context (invalid function)

• Functions that both can perform. (I lied there 3)

When you call the reactive function , it creates a context that stores meteorites around the world and to which the reactive function subscribes an invalidation callback. The function that you pass to the reactive function or any functions that run inside it can be an invalidating function and can capture the current context and store it locally. These functions can then at any time, for example, when updating db or just calling the timer, that context invalid. The initial reactive function will then receive this event and reevaluate itself.

Here, step by step, using the meteor functions (note that Tracker.autorun was called Deps.autorun ):

 Tracker.autorun(function(){ alert("Hello " + Session.get("name")); }); Session.set("name", "Greg"); 

• autorun takes a function as a parameter
• autostart creates context before running this function
• autorun attaches a callback to an invalid event context
• This callback will re-run the function passed to the autoloader
• The function then runs in context for the first time.
• Meteor saves this context globally as the current active context
• There is another function inside the function: Session.get ()
• Session.get () is both a reactive function and an invalidating function
• Session.get sets its own context and associates it internally with the name key
• Session.get retrieves the current context (autostart context) globally from the meteor
• The invalidation callback that Session.get registers in its own context will simply invalidate its inclusion context (in this case, the startup context)
• So now we have 2 contexts: autorun and session.get

• when these functions return, the meteorite clears the global variable of the active context

• Session.set is another function that can lead to invalid context .

• in this case we will cancel all context created by the session associated with the key "name"
• All those contexts , when they are invalid, trigger their invalid callbacks.
• These callbacks are simply invalid for their inclusion context (that is the design of Session.get, and not what the invalidation callback should do)
• Those who conclude contexts now execute their invalidation callbacks.
• In the case of autorun, this callback starts the function that we initially passed to autorun, and then sets context again.

The whole implementation is actually quite straightforward, you can see it here:
https://github.com/meteor/meteor/blob/master/packages/tracker/tracker.js

And a good example of how this works can be found here:
https://github.com/meteor/meteor/blob/master/packages/reactive-dict/reactive-dict.js

Reactive programming is not really meteoric or JS-specific
you can read about it here: http://en.wikipedia.org/wiki/Reactive_programming