Używanie sukcesu / błędu / w końcu / złap z obietnicami w AngularJS

Używam $httpw AngularJs i nie jestem pewien, jak używać zwróconej obietnicy i radzić sobie z błędami.

Mam ten kod:

$http
    .get(url)
    .success(function(data) {
        // Handle data
    })
    .error(function(data, status) {
        // Handle HTTP error
    })
    .finally(function() {
        // Execute logic independent of success/error
    })
    .catch(function(error) {
        // Catch and handle exceptions from success/error/finally functions
    });

Czy to dobry sposób, czy jest łatwiejszy sposób?

Obietnice są abstrakcją w stosunku do instrukcji, które pozwalają nam wyrażać siebie synchronicznie za pomocą kodu asynchronicznego. Reprezentują wykonanie jednorazowego zadania.

Zapewniają również obsługę wyjątków, podobnie jak normalny kod, możesz powrócić z obietnicy lub możesz rzucić.

To, czego chciałbyś w kodzie synchronicznym, to:

try{
  try{
      var res = $http.getSync("url");
      res = someProcessingOf(res);
  } catch (e) {
      console.log("Got an error!",e);
      throw e; // rethrow to not marked as handled
  }
  // do more stuff with res
} catch (e){
     // handle errors in processing or in error.
}

Obiecana wersja jest bardzo podobna:

$http.get("url").
then(someProcessingOf).
catch(function(e){
   console.log("got an error in initial processing",e);
   throw e; // rethrow to not marked as handled, 
            // in $q it's better to `return $q.reject(e)` here
}).then(function(res){
    // do more stuff
}).catch(function(e){
    // handle errors in processing or in error.
});

Zapomnij o używaniu successi errormetodzie.

Obie metody zostały wycofane w wersji kątowej 1.4. Zasadniczo powodem wycofania jest to, że nie są one przyjazne dla łańcuchów , że tak powiem.

Dzięki poniższym przykładzie postaram się wykazać, co mam na myśli około successi errorjest nie chainable w obsłudze . Załóżmy, że wywołujemy API, które zwraca obiekt użytkownika o adresie:

Obiekt użytkownika:

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

Zadzwoń do 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'}
    });
};

Co się stało?

Ponieważ successi errorzwraca pierwotną obietnicę , tj. Tę zwróconą przez $http.get, obiekt przekazany do wywołania zwrotnego thenjest całym obiektem użytkownika , to znaczy tym samym wejściem do poprzedniego successwywołania zwrotnego.

Gdybyśmy połączyli dwa łańcuchy then, byłoby to mniej zagmatwane:

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

Myślę, że poprzednie odpowiedzi są poprawne, ale oto inny przykład (tylko fyi, success () i error () są przestarzałe zgodnie ze stroną główną AngularJS :

$http
    .get('http://someendpoint/maybe/returns/JSON')
    .then(function(response) {
        return response.data;
    }).catch(function(e) {
        console.log('Error: ', e);
        throw e;
    }).finally(function() {
        console.log('This finally block');
    });

Jakiego rodzaju szczegółowości szukasz? Zwykle możesz sobie poradzić z:

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

Odkryłem, że „nareszcie” i „złapanie” są lepsze, gdy wiąże się wiele obietnic.

W przypadku Angular $ http funkcje success () i error () będą miały obiekt odpowiedzi rozpakowany, więc sygnatura wywołania zwrotnego będzie wyglądać następująco: $ http (...). Success (function (data, status, headers, config))

dla then () prawdopodobnie zajmiesz się surowym obiektem odpowiedzi. takie jak opublikowane w dokumencie API AngularJS $ http

$http({
        url: $scope.url,
        method: $scope.method,
        cache: $templateCache
    })
    .success(function(data, status) {
        $scope.status = status;
        $scope.data = data;
    })
    .error(function(data, status) {
        $scope.data = data || 'Request failed';
        $scope.status = status;
    });

Ostatni .catch (...) nie będzie potrzebny, chyba że w poprzednim łańcuchu obietnic pojawi się nowy błąd.

Robię to tak, jak sugeruje Bradley Braithwaite na swoim blogu :

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;
            });
    }])

Kluczowe punkty:

• Funkcja rozwiązywania łączy się z funkcją .then w naszym kontrolerze, czyli wszystko jest w porządku, więc możemy dotrzymać obietnicy i rozwiązać ją.

• Funkcja odrzucania łączy się z funkcją .catch w naszym kontrolerze, czyli coś poszło nie tak, więc nie możemy dotrzymać obietnicy i musimy ją odrzucić.

Jest dość stabilny i bezpieczny, a jeśli masz inne warunki, aby odrzucić obietnicę, zawsze możesz filtrować swoje dane w funkcji sukcesu i dzwonić deferred.reject(anotherReason)z przyczyną odrzucenia.

Jak zasugerował Ryan Vice w komentarzach , może to nie być postrzegane jako przydatne, chyba że będziesz trochę bawić się odpowiedzią, że tak powiem.

Ponieważ successi errorsą przestarzałe od wersji 1.4, być może lepiej jest użyć zwykłych metod obietnicy thenicatch i przekształcenia odpowiedzi w tych metodach i powrócić obietnicę tej przekształconej odpowiedzi.

Pokazuję ten sam przykład z obydwoma podejściami i trzecim podejściem pośrednim:

successi errorpodejdź ( successi errorzwróć obietnicę odpowiedzi HTTP, więc potrzebujemy pomocy, $qaby zwrócić obietnicę danych):

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;
};

theni catchpodejście (jest to trochę trudniejsze do przetestowania ze względu na rzut):

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;
}

Istnieje jednak rozwiązanie połowiczne (w ten sposób możesz uniknąć, throwa mimo to prawdopodobnie będziesz musiał użyć, $qaby kpić z obiecującego zachowania w swoich testach):

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;
}

Wszelkie uwagi i poprawki są mile widziane.