À l'aide de succès/erreur/enfin/catch avec des Promesses en AngularJS

Oublier d'utiliser success et error méthode.

Les deux méthodes ont été dépréciés dans angulaire 1.4. Fondamentalement, la raison derrière l'autodérision, c'est qu'ils ne sont pas chainable-friendly, pour ainsi dire.

Avec l'exemple suivant, je vais essayer de démontrer ce que je veux dire, success et error n'étant pas chainable-friendly. Supposons que nous appelons une API qui retourne un objet utilisateur avec une adresse:

De l'utilisateur de l'objet:

{name: 'Igor', address: 'San Francisco'}

Appel à l'API:

$http.get('/user')
    .success(function (user) {
        return user.address;   <---  
    })                            |  //you might expect that 'obj' is equal to the
    .then(function (obj) {   ------  //address of the user, but it is NOT

        console.log(obj); //-> {name: 'Igor', address: 'San Francisco'}
    });
};

Ce qui s'est passé?

Parce que success et error retour de la promesse d'origine, c'est à dire celui retourné par $http.get, l'objet passé à la fonction de rappel de la then est l'ensemble de la utilisateur objet, c'est-à-dire la même entrée à la précédente success de rappel.

Si l'on avait enchaîné deux then, cela aurait été moins à confusion:

$http.get('/user')
    .then(function (user) {
        return user.address;  
    })
    .then(function (obj) {  
        console.log(obj); //-> 'San Francisco'
    });
};

Ce type de granularité cherchez-vous? Vous pouvez généralement obtenir en avec:

$http.get(url).then(
  //success function
  function(results) {
    //do something w/results.data
  },
  //error function
  function(err) {
    //handle error
  }
);

J'ai trouvé que "enfin" et "catch" sont mieux quand le chaînage de plusieurs promesses.

Je ne l'aime Bradley Braithwaite suggère dans son blog:

app
    .factory('searchService', ['$q', '$http', function($q, $http) {
        var service = {};

        service.search = function search(query) {
            //We make use of Angular's $q library to create the deferred instance
            var deferred = $q.defer();

            $http
                .get('http://localhost/v1?=q' + query)
                .success(function(data) {
                    //The promise is resolved once the HTTP call is successful.
                    deferred.resolve(data);
                })
                .error(function(reason) {
                    //The promise is rejected if there is an error with the HTTP call.
                    deferred.reject(reason);
                });

            //The promise is returned to the caller
            return deferred.promise;
        };

        return service;
    }])
    .controller('SearchController', ['$scope', 'searchService', function($scope, searchService) {
        //The search service returns a promise API
        searchService
            .search($scope.query)
            .then(function(data) {
                //This is set when the promise is resolved.
                $scope.results = data;
            })
            .catch(function(reason) {
                //This is set in the event of an error.
                $scope.error = 'There has been an error: ' + reason;
            });
    }])

Points Clés:

• La détermination de la fonction des liens de la .puis en fonction de notre contrôleur c'est à dire que tout va bien, afin que nous puissions tenir notre promesse et de le résoudre.

• La rejeter fonction des liens de la .fonction capture dans notre contrôleur de dire quelque chose allait mal, donc on ne peut pas tenir notre promesse et de la nécessité de
  rejeter.

Il est tout à fait stable et sûr, et si vous avez d'autres conditions de rejeter la promesse, vous pouvez toujours filtrer vos données dans la réussite de la fonction et l'appel deferred.reject(anotherReason) la raison du rejet.

Comme Ryan Vice suggéré dans les commentaires, cela peut ne pas être considéré comme utile, sauf si vous tripoter un peu de la réponse, pour ainsi dire.

Parce que success et error sont dépréciées depuis la 1.4 c'est peut-être mieux pour l'utilisation de l'promesse méthodes then et catch et de transformer la réponse à l'intérieur de ces méthodes et le retour de la promesse de la transformée de réponse.

Je suis en train de montrer le même exemple avec les deux approches, et un troisième entre approche:

success et error approche (success et error retour d'une promesse d'une réponse HTTP, donc nous avons besoin de l'aide de $q de retour d'une promesse de données):

function search(query) {
  //We make use of Angular's $q library to create the deferred instance
  var deferred = $q.defer();

  $http.get('http://localhost/v1?=q' + query)
  .success(function(data,status) {
    //The promise is resolved once the HTTP call is successful.
    deferred.resolve(data);              
  })

  .error(function(reason,status) {
    //The promise is rejected if there is an error with the HTTP call.
    if(reason.error){
      deferred.reject({text:reason.error, status:status});
    }else{
      //if we don't get any answers the proxy/api will probably be down
      deferred.reject({text:'whatever', status:500});
    }
  });

  //The promise is returned to the caller
  return deferred.promise;
};

then et catch approche (c'est un peu plus difficile à tester, en raison de la jeter):

function search(query) {

  var promise=$http.get('http://localhost/v1?=q' + query)

  .then(function (response) {
    //The promise is resolved once the HTTP call is successful.
    return response.data;
  },function(reason) {
    //The promise is rejected if there is an error with the HTTP call.
    if(reason.statusText){
      throw reason;
    }else{
      //if we don't get any answers the proxy/api will probably be down
      throw {statusText:'Call error', status:500};
    }

  });

  return promise;
}

Il y a une solution intermédiaire si, de cette façon, vous pouvez éviter la throw et de toute façon, vous aurez probablement besoin d'utiliser $q pour se moquer de la promesse de comportement dans vos tests):

function search(query) {
  //We make use of Angular's $q library to create the deferred instance
  var deferred = $q.defer();

  $http.get('http://localhost/v1?=q' + query)

  .then(function (response) {
    //The promise is resolved once the HTTP call is successful.
    deferred.resolve(response.data);
  },function(reason) {
    //The promise is rejected if there is an error with the HTTP call.
    if(reason.statusText){
      deferred.reject(reason);
    }else{
      //if we don't get any answers the proxy/api will probably be down
      deferred.reject({statusText:'Call error', status:500});
    }

  });

  //The promise is returned to the caller
  return deferred.promise;
}

Toute sorte de commentaires ou corrections sont les bienvenues.