web-dev-qa-db-fra.com

Meteor s'abonner rappel

Selon cet article ici:

https://dweldon.silvrback.com/common-mistakes

Les abonnements ne bloquent pas

De nombreux aspects du cadre semblent magiques. À tel point que cela peut vous faire oublier le fonctionnement des navigateurs Web. Prenez cet exemple simple:

Meteor.subscribe ("messages");

var post = Posts.findOne ();

L'idée que la publication ne sera pas définie est la cause principale d'environ une question de météore sur vingt sur stackoverflow.

Alors, pourquoi l'abonnement n'a-t-il pas de rappel, et si c'est le cas, pourquoi n'est-il pas référencé plus souvent par les lettrés Meteor?

Pourquoi n'avons-nous pas:

Meteor.subscribe('posts', function(err, posts){

//when the items/posts actually arrive

});

J'espère que ma question a un sens.

meteor
25
Alexander Mills

Peut-être que je ne comprends pas la question, mais la fonction Meteor.Subscribe a des rappels nommés méthodes onError et onReady.

Optionnel. Peut inclure des rappels onError et onReady. Si une fonction est passée à la place d'un objet, elle est interprétée comme un rappel onReady.

D'après les documents.

Par exemple.

Meteor.subscribe("posts", {
  onReady: function () { console.log("onReady And the Items actually Arrive", arguments); },
  onError: function () { console.log("onError", arguments); }
});

Vérifiez également cela problème GitHub

50
Ethaan

Remarque: j'ai mis à jour l'article après avoir lu cette question.

Bien que s'abonner ait un rappel facultatif, je l'ai intentionnellement évité dans l'article d'origine car il n'y a actuellement aucun modèle courant qui l'utilise. En d'autres termes, je ne voulais pas que les lecteurs se détournent de l'article en pensant que les rappels étaient en fait la bonne solution à ce problème.

Dans les applications de production, les abonnements se présentent généralement en deux versions:

  • Global: initié dès le démarrage du client, ou peut-être en exécution automatique.

  • Route: initiée comme via un subscriptions ou waitOnoption .

Il convient également de noter que ces dernières semaines, le modèle d'abonnement au modèle a émergé, bien qu'il n'ait pas encore été largement adopté.

Dans tous ces cas, l'abonnement est démarré et peut ensuite être vérifié de manière asynchrone pour un état réactif ready, ou ignoré avec l'utilisation de gardes pour éviter les erreurs de référence.

Parce que ready est réactif, cela nous donne effectivement les mêmes avantages d'un rappel, mais avec moins de lignes de code. Regardons deux exemples:

exemple 1

Meteor.subscribe('posts', function() {
  Session.set('postsReady', true);
});

Tracker.autorun(function() {
  if (Session.get('postsReady'))
    showFancyAnimation();
});

exemple 2

var handle = Meteor.subscribe('posts');

Tracker.autorun(function() {
  if (handle.ready())
    showFancyAnimation();
});

Les deux exemples illustrent le même concept - abonnement puis test réactif de l'état de l'abonnement. Comme vous pouvez le voir, le rappel n'a vraiment aucun avantage.

Enfin, (comme je le souligne maintenant dans l'article), les abonnements sont souvent séparés spatialement du code qui les utilise. Vous vous abonnerez généralement dans votre code d'itinéraire et consommerez les résultats dans vos modèles. Pour cette raison, vous ne voyez presque jamais de code qui ressemble à:

Meteor.subscribe('posts', function() {
  showFancyAnimation();
});

En fait, le seul endroit où je rencontre du code comme celui-ci est dans SO réponses parce que l'auteur essaie de faire une démonstration rapide plutôt que d'essayer de montrer un modèle d'utilisation typique.

20
David Weldon

Meteor.subscribe a été amélioré depuis la version 1.2. L'un de ses rappels onError est maintenant remplacé par onStop dans la documentation Meteor v1.2.0.2

fonction ou objet de rappel

Optionnel. Peut inclure des rappels onStop et onReady. S'il y a une erreur, elle est passée en argument à onStop. Si une fonction est passée à la place d'un objet, elle est interprétée comme un rappel onReady.

Ayant cette amélioration, Meteor.subscribe est utilisé avec les rappels en tant qu'objet

Meteor.subscribe( 'collection', {
    onStop:  function( error /* optional */ ) {
        // when the sub terminates for any reason,
        // with an error argument if an error triggered the stop
    },
    onReady: function() {
        // when ready
    }
});

Cependant, onError fonctionne toujours pour la compatibilité descendante. Sachez que certains packages populaires, tels que SubsManager utilisent toujours onError. Cela étant dit, tel extrait ci-dessous est désormais obsolète mais ne se casse pas.

Meteor.subscribe( 'collection', {
    onError: function( error ) {
        // if the subscribe terminates with an error
    },
    onReady: function() {
        // when ready
    }
});

D'autre part, Meteor.subscribe peut être utilisé avec une fonction de rappel comme auparavant

Meteor.subscribe( 'collection', function() {
    // when ready
});

À titre personnel, si Meteor.subscribe se trouve être passé avec plusieurs fonctions de rappel négligentes, seule la dernière prend effet en tant que rappel onReady.

Meteor.subscribe( 'collection', function() {
    // this doesn't execute.
}, function() {
    // when ready.
});

L'engagement Git associé est répertorié ici pour référence.

12
Season