2017-10-04 7 views
0

Je dois retourner une réponse personnalisée dans une promesse, à partir d'un appel $ http, afin que je puisse enchaîner d'autres appels. J'ai deux implémentations disponibles. Quelqu'un peut-il expliquer la différence entre deux, et argumenter si l'on est meilleur?

Dans fooService.js

Application # 1

function foo() { 
    var deferred = $q.defer(); 
    return $http.get('some-http-url') 
     .then(function(response) { 
      var data = response.data.Data; 
      // Some manipulation on data 
      deferred.resolve(data); 
      return deferred.promise; 
     }); 
} 

Mise en œuvre # 2

function foo() { 
    return $http.get('some-http-url') 
     .then(function(response) { 
      var data = response.data.Data; 
      // Some manipulation on data 
      return $q.resolve(data); 
     }); 
} 

Et puis dans FooController.js

fooService.foo().then(function(response) { 
    // Do something 
}); 

P.S. Certains liens, qui peuvent me donner une meilleure compréhension sont les bienvenus.


************** MISE À JOUR 4ème Octobre, 2017 **************

Si Je modifie ma fonction foo() comme celui-ci

Application # 1

function foo() { 
    var deferred = $q.defer(); 
    if(/*some condition*/) { 
     deferred.resolve('data'); 
     return deferred.promise; 
    } 
    else { 
     deferred.reject('error'); 
     return deferred.promise; 
    } 
} 

Mise en œuvre # 2

function foo() { 
    if(/*some condition*/) 
     return $q.resolve('data'); 
    else 
     return $q.reject('error'); 
} 

Quelle est la façon préférée?

Répondre

2

Vous n'avez pas besoin de $q ici, car $http déjà returns a promise. Il suffit de retourner les données dans .then() et il sera disponible pour la prochaine .then() de la chaîne:

function foo() { 
    return $http.get('some-http-url') 
     .then(function(response) { 
      return response.data.Data; 
     }); 
} 

La façon dont vous faites votre mise en œuvre est appelée deferred antipattern, plus d'informations en this answer.

+0

Cela fonctionne merci! –