Meteor的反应性如何在幕后工作？

Question

我已阅读docs并查看source behind reactivity，但我不明白。

有人可以在幕后解释这是如何工作的，因为它对我来说看起来很神奇：）。

Answer 1

所以它实际上相当直接，在基本层面上涉及两种类型的函数：

1. 创建反应性上下文的函数（反应函数）

2. 使无效上下文无效的功能（使功能无效）

3. 可以兼顾两者的功能。 （我说谎有3个）

当你拨打reactive function时，它会创建一个context全球流媒体存储的reactive function，invalidation订阅invalidating function回调。传递给反应函数的函数或从其中运行的任何函数可以是context，可以获取当前context并将其存储在本地。这些函数可以随时在数据库更新或简单的计时器调用中使reactive function无效。原来的Tracker.autorun会收到该事件并重新评估自己。

以下是使用流星函数的一步一步（请注意Deps.autorun曾被称为Tracker.autorun(function(){ alert("Hello " + Session.get("name")); }); Session.set("name", "Greg"); ）：

context

1. autorun将函数作为其参数
2. 在自动运行之前运行此功能，它会创建一个context
3. autorun将回调附加到context的失效事件
4. 此回调将重新运行传递给autorun的函数
5. 然后该功能首次在context中运行。
6. Meteor将此context全局存储为当前有效的reactive function
7. 函数内部是另一个函数：Session.get（）
8. Session.get（）既是invalidating function又是context
9. Session.get设置它自己的context并在内部将其与关键字“name”关联
10. Session.get从meteor
全局检索当前上下文（autorun的上下文）
11. Session.get注册到它自己的上下文的失效回调，只会使它的封闭上下文无效（在这种情况下，自动运行的上下文）
12. 所以现在我们有2个上下文，autorun's和session.get's

13. 当这些函数返回时，meteor会清理活动的上下文全局变量

14. Session.set是另一个能够使context无效的功能。

15. 在这种情况下，我们将与关键字“name”关联的Session创建的所有contexts无效
16. 所有这些context在失效时运行其无效回调。
17. 这些回调只会使其封闭的contexts无效（这是Session.get的设计，而不是无效回调必须做的事情）
18. 围绕context的人现在运行无效回调。
19. 在自动运行的情况下，该回调运行我们最初传递给自动运行的函数，然后再次设置{{1}}。

整个实施实际上也很直接，你可以在这里看到：
https://github.com/meteor/meteor/blob/master/packages/tracker/tracker.js

这里有一个很好的例子，可以在这里找到：
https://github.com/meteor/meteor/blob/master/packages/reactive-dict/reactive-dict.js

反应式编程实际上不是流星或JS特定的
你可以在这里阅读：http://en.wikipedia.org/wiki/Reactive_programming