AngularJS Gérer différents codes d'erreur à différents endroits

Question

J'ai un service qui contient un appel générique à $ http que tous les appels ajax utilisent. Ici, j'ai la gestion des erreurs "centralisée" où les codes de statut entraîne des redirections.

Service « FieldsSync »:

return $http({ 
    method: 'POST', 
    url: url, 
    data: $.extend(defaultPostData, postData) 
}).error(function(data, status) { 
    switch (status) { 
     case 401: // "Unauthorized". Not logged in. 
      redirect.toLoginPage(); 
      break; 
     case 403: // "Forbidden". Role has changed. 
      redirect.toLogoutPage(); 
      break; 
    } 
}); 

Lorsque vous appelez une des fonctions de service du contrôleur que je retourne toujours l'objet différé pour pouvoir brancher plusieurs callbacks d'erreur pour pouvoir gérer les erreurs qui devraient résulter dans une sorte de rétroaction pour l'utilisateur.

Controller:

fieldsSync.createField(newField).success(function(data) { 
    ... 
}).error(function(data, status) { 
    switch (status) { // <--- DO NOT WANT 
     case 401: 
     case 403: 
      return; // These errors are handled (=redirects) in the generic error callback and we don't want to show do anything while it redirects. 
    } 
    ... // "Individual" error handling. =Displaying messages and stuff 
}); 

Mais parce que je ne veux pas les messages d'erreur apparaître avant que la redirection se produit, je dois quitter la fonction de rappel d'erreur si les codes d'état ont déjà été traités.

La question est: Comment puis-je me débarrasser des boîtiers de commutation dans mes contrôleurs? Est-il possible de quitter la chaîne des rappels d'erreur lorsqu'un code d'erreur spécifique a été traité? Ou est-il possible de contourner cela d'une manière moins laide? :)

Ceci est un problème récurrent pour moi, et mon esprit semble coincé.

J'ai vérifié les docs et je ne peux pas trouver de solution pour cela dans $ http ou $ q.

Answer 1

Je vous propose d'utiliser un responseInterceptor pour traiter ces cas.

http://docs.angularjs.org/api/ng $ http

J'ai écrit ce qui suit, quand j'eu le même « problème » que vous. Son seul un premier projet, mais vous pouvez l'améliorer à vos besoins

InternalServerErrorResponseInterceptor = function($q, InternalServerErrorService) { 
    return function(promise) { 
     return promise.then(function(response) { 
      return response; 
     }, function(response) { 
      if (response.status > 499) { 
       InternalServerErrorService.handleError(); 
       return $q.reject(response); 
      } 
      return $q.reject(response); 
     }); 
    }; 
}; 
module.factory('InternalServerErrorResponseInterceptor', ['$q', 'InternalServerErrorService', InternalServerErrorResponseInterceptor]); 
module.config(['$httpProvider', function($httpProvider) { 
     $httpProvider.responseInterceptors.push('InternalServerErrorResponseInterceptor'); 
    }]); 

Maintenant, votre InternalServerErrorService spécifique peut gérer la façon dont vous voulez qu'il soit géré :)

ce qui concerne

Answer 2

Une solution que je propose est de refaire les fonctions de synchronisation (puh!) Afin qu'ils ne retournent pas l'objet différé. Les fonctions à l'intérieur du service pourraient prendre les callbacks comme arguments. Je pourrais alors vérifier si l'erreur a déjà été traitée par la gestion générique des erreurs avant qu'elle ne soit appelée.

pseudocode:

Service:

fieldsSync.createField(newField, successCallback, failCallback) { 
    ... 
    genericErrorHandlerResultingInRedirects() 
    if (not 401 || 403) { 
     failCallback() 
    } 
}; 

Controller:

fieldsSync.createField({}, function successCallback(){}, function failCallback(){ 
    /* Handle errors that should give the user feedback */ 
}); 

D'autres solutions sont les bienvenues.