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");

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

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

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

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

整个实现实际上也相当简单，您可以在此处查看：
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