Comment Météore de la réactivité de derrière les coulisses?

Question

J'ai lu les docs et regarda la source derrière la réactivité, mais je ne le comprends pas.

Quelqu'un peut m'expliquer comment cela fonctionne en arrière-plan, comme il ressemble à de la magie pour moi :).

Answer 1

Donc c'est plutôt normal, à un niveau de base il y a 2 types de fonctions:

1. Des fonctions qui créent un réactif contexte (réactif de fonction)

2. Fonctions annuler un réactif contexte (invalidation de la fonction)

3. Les fonctions qui peuvent faire les deux. (J'ai menti, il ya 3)

Lorsque vous appelez un reactive function il crée un context que meteor magasins à l'échelle mondiale et à qui l' reactive function s'abonne à un invalidation de rappel. La fonction que vous passez à un réactif de fonction, ou toutes les fonctions de l'intérieur, peut être un invalidating function et peut attirer l'actuel context et les stocker localement. Ces fonctions peuvent ensuite, à tout moment, comme sur un db de mise à jour ou tout simplement d'une minuterie d'appel, d'infirmer cette context. L'original de l' reactive function serait alors de recevoir cet événement et de ré-évaluer.

Voici une étape par étape à l'aide de meteor fonctions:

Deps.autorun(function(){ 
  alert("Hello " + Session.get("name"));
});

Session.set("name", "Greg");

1. autorun prend une fonction comme paramètre
2. avant l'exécution automatique s'exécute cette fonction, il crée un context
3. autorun attache à un rappel à l' contexts'invalidation de l'événement
4. Ce rappel permettra de ré-exécuter la fonction transmise pour exécution automatique
5. La fonction est alors exécuté dans l' context , pour la première fois.
6. Meteor magasins cette context à l'échelle mondiale que l'actif context
7. L'intérieur de la fonction est une autre fonction: Session.get()
8. Session.get() est à la fois un reactive function et invalidating function
9. Session.obtenir définit ses propres context , et l'associe à l'interne avec la clé "nom"
10. Session.obtenir récupère le contexte actuel (autorun du contexte) à l'échelle mondiale à partir de meteor
11. L'invalidation de rappel de la Session.obtenir les registres de son propre contexte, tout simplement invalider c'est en joignant contexte (dans ce cas, l'exécution automatique du contexte)
12. Alors maintenant, nous avons 2 contextes, l'autorun et de session.obtenez de l'

13. lorsque ces fonctions renvoient, meteor nettoie le contexte actif variable globale

14. Session.ensemble est une autre fonction capable d'invalider un context.

15. dans ce cas, nous avons invalider tous contexts créé par Session associée à la clé "nom"
16. Tous ceux - contexts, lors de l'invalidation d'exécuter leur invalidation des rappels.
17. Ces rappels juste invalider leur joignant contexts (C'est la conception de la Séance.obtenir et pas ce que l'invalidation de rappel doit le faire)
18. Ceux enfermant contexts maintenant exécuter leur invalidation des rappels.
19. Dans ce cas, que le rappel s'exécute la fonction que nous avons passé initialement autorun et puis l' context de nouveau.

L'ensemble de la mise en œuvre est en réalité assez simple que le fait de bien, vous pouvez le voir ici:
https://github.com/meteor/meteor/blob/master/packages/deps/deps.js

Et un bon exemple de comment cela fonctionne peuvent être trouvés ici:
https://github.com/meteor/meteor/blob/master/packages/reactive-dict/reactive-dict.js

autoruns mise en œuvre est ici:
https://github.com/meteor/meteor/blob/master/packages/deps/deps.js#L250

Réactif de programmation n'est pas réellement météore ou JS spécifique
vous pouvez lire à ce sujet ici: http://en.wikipedia.org/wiki/Reactive_programming