AngularJS : Où utiliser promesses?

Ce n'est pas une réponse complète à votre question, mais j'espère que cela va vous aider, vous et d'autres personnes lorsque vous essayez de lire la documentation sur le $q service. Il m'a fallu un certain temps pour le comprendre.

Laissons de côté AngularJS pour un moment, et il suffit de considérer le Facebook des appels d'API. À la fois les appels d'API utiliser un rappel mécanisme pour informer l'appelant lorsque la réponse de Facebook est disponible:

  facebook.FB.api('/' + item, function (result) {
    if (result.error) {
      //handle error
    } else {
      //handle success
    }
  });
  //program continues while request is pending
  ...

C'est un modèle standard pour la manipulation des opérations asynchrones en JavaScript et d'autres langages.

Un gros problème avec ce modèle se pose lorsque vous avez besoin pour effectuer une séquence d'opérations asynchrones, où chaque opération dépend du résultat de l'opération précédente. C'est ce que ce code est fait:

  FB.login(function(response) {
      if (response.authResponse) {
          FB.api('/me', success);
      } else {
          fail('User cancelled login or did not fully authorize.');
      }
  });

D'abord, il essaie de se connecter, puis seulement après avoir vérifié que la connexion a réussi t-il en faire la demande à l'API Graphique.

Même dans ce cas, qui est le seul à enchaîner deux opérations, les choses commencent à déraper. La méthode askFacebookForAuthentication accepte un rappel de l'échec et de la réussite, mais ce qui arrive quand FB.login réussit, mais FB.api échoue? Cette méthode appelle toujours le success rappel quel que soit le résultat de la FB.api méthode.

Maintenant, imaginez que vous êtes en train de coder un robuste séquence de trois ou plus des opérations asynchrones, d'une manière qui gère correctement les erreurs à chaque étape et sera lisible pour quelqu'un d'autre ou même après quelques semaines. Possible, mais il est très facile de simplement continuer à la nidification de ces rappels et de perdre la trace des erreurs le long du chemin.

Maintenant, laissons de côté l'Facebook API, pour un moment, et il suffit de considérer l'angle de Promesses API, mis en place par le $q service. Le modèle mis en œuvre par ce service est une tentative de tourner la programmation asynchrone en arrière en quelque chose ressemblant à une série linéaire de déclarations simples, avec la possibilité de lancer une erreur à n'importe quelle étape de la voie et de le traiter à la fin, sémantiquement similaire à l'familier try/catch bloc.

Considérer cet exemple artificiel. Disons que nous avons deux fonctions, d'où la deuxième fonction qui consomme le résultat de la première:

 var firstFn = function(param) {
    //do something with param
    return 'firstResult';
 };

 var secondFn = function(param) {
    //do something with param
    return 'secondResult';
 };

 secondFn(firstFn()); 

Maintenant, imaginez que firstFn et secondFn ont tous deux une longue période de temps, si l'on veut traiter cette séquence de façon asynchrone. Nous avons d'abord créer un nouveau deferred objet, ce qui représente une chaîne d'opérations:

 var deferred = $q.defer();
 var promise = deferred.promise;

La promise propriété représente le résultat final de la chaîne. Si vous vous connectez une promesse immédiatement après la création, vous allez voir que c'est juste un objet vide ({}). Rien à voir pourtant, aller à droite le long.

Jusqu'à présent notre promesse ne représente que le point de départ de la chaîne. Maintenant, nous allons ajouter nos deux opérations:

 promise = promise.then(firstFn).then(secondFn);

La then méthode ajoute une étape à la chaîne et renvoie une nouvelle promesse représentant le résultat final de l'extension de la chaîne. Vous pouvez ajouter autant d'étapes que vous le souhaitez.

Jusqu'à présent, nous avons mis en place notre chaîne de fonctions, mais rien de ce qui s'est réellement passé. Vous obtenez les choses ont commencé par l'appel de deferred.resolve, en spécifiant la valeur initiale que vous souhaitez passer à la première étape de la chaîne:

 deferred.resolve('initial value');

Et puis...toujours rien ne se passe. Pour s'assurer que les changements de modèle sont bien suivies, Angulaire n'a pas fait appel de la première étape de la chaîne jusqu'à la prochaine fois $apply est appelé:

 deferred.resolve('initial value');
 $rootScope.$apply();

 //or     
 $rootScope.$apply(function() {
    deferred.resolve('initial value');
 });

Ainsi que sur la gestion des erreurs? Jusqu'à présent, nous avons seulement indiqué une gestionnaire de succès à chaque étape de la chaîne. then accepte également un gestionnaire d'erreur, comme un deuxième argument optionnel. En voici un autre, plus l'exemple d'une promesse de la chaîne, cette fois avec la gestion des erreurs:

 var firstFn = function(param) {
    //do something with param
    if (param == 'bad value') {
      return $q.reject('invalid value');
    } else {
      return 'firstResult';
    }
 };

 var secondFn = function(param) {
    //do something with param
    if (param == 'bad value') {
      return $q.reject('invalid value');
    } else {
      return 'secondResult';
    }
 };

 var thirdFn = function(param) {
    //do something with param
    return 'thirdResult';
 };

 var errorFn = function(message) {
   //handle error
 };

 var deferred = $q.defer();
 var promise = deferred.promise.then(firstFn).then(secondFn).then(thirdFn, errorFn);

Comme vous pouvez le voir dans cet exemple, chaque gestionnaire de la chaîne a l'occasion de détourner le trafic vers la prochaine erreur gestionnaire au lieu de la prochaine succès gestionnaire. Dans la plupart des cas, vous pouvez avoir un seul gestionnaire d'erreur à la fin de la chaîne, mais vous pouvez aussi avoir l'intermédiaire des gestionnaires d'erreur que la tentative de récupération.

Pour revenir rapidement à vos exemples et vos questions), je vais juste dire qu'elles représentent deux manières différentes pour s'adapter Facebook callback de l'API orientée Angulaire de la voie de l'observation des changements de modèle. Le premier exemple encapsule l'appel d'API en une promesse, qui peut être ajouté à un champ d'application et est entendu par Angulaire du système de template. Le second prend le plus de force brute approche de définition de la fonction de rappel directement le résultat sur le champ, puis en appelant $scope.$digest() de faire Angulaire au courant du changement à partir d'une source externe.

Les deux exemples ne sont pas directement comparables, car la première est manquant, l'étape de connexion. Cependant, il est généralement souhaitable d'encapsuler les interactions avec les Api externe de ce genre dans des services distincts, et d'envoyer les résultats aux contrôleurs que des promesses. De cette façon, vous pouvez garder vos contrôleurs séparés de préoccupations externes, et de les tester plus facilement avec des simulations de services.

Un différé représente le résultat d'une opération asynchrone. Il expose une interface qui peut être utilisée pour la signalisation de l'état et le résultat de l'opération qu'elle représente. Il fournit également un moyen d'obtenir la promesse de l'instance.

Une promesse fournit une interface pour interagir avec il est différé, et donc, permet aux parties intéressées d'avoir accès à l'état et à la suite de l'opération différée.

Lors de la création d'un différé, c'est l'état est en attente et il n'a pas de résultat. Lorsque nous résoudre (ou de rejeter) le report de la, il change d'état à résoudre ou rejeté. Néanmoins, nous pouvons obtenir la promesse immédiatement après la création d'un reportés et même affecter les interactions avec elle l'avenir du résultat. Ces interactions ne se feront qu'après le différé rejeté ou de les résoudre.