Exemple détaillé d'encapsulation AngularJS $http.post()

Cet article présente principalement les informations pertinentes sur les exemples AngularJS encapsulant $http.post() en détail. Les amis dans le besoin peuvent se référer à

AngularJS encapsulant $http.post. () Explication détaillée des exemples

Il m'a fallu peu de temps pour suivre un projet d'application mobile, utilisant ionic + AngularJS + cordovaframework, et j'ai rencontré beaucoup de problèmes. , dont l'un est le problème d'encapsulation d'Ajax.

En fait, nous n'avons jamais cessé de parler des problèmes d'emballage. Différents projets ont aussi des besoins différents. Pour donner un exemple typique, lorsque je travaillais sur ce projet, je n'ai pas pris en compte les problèmes d'emballage. début a été critiqué, et un de mes amis a été critiqué pour l'encapsulation... C'est embarrassant, n'est-ce pas ?

Alors, comment devrions-nous définir s'il faut encapsuler ? En fait, ce n'est pas une question très compliquée. En dernière analyse, il s'agit d'une question de ratio de revenus. Si l'échelle du projet n'est pas très grande, cela n'a aucun sens de trop considérer la question de l'emballage du projet. est extrêmement faible ; et pour des projets à grande échelle, cela n'a aucun sens. Cela dit, s'il n'y a pas d'encapsulation, les risques potentiels sont beaucoup plus élevés, donc l'investissement initial en vaut la peine.

Bien sûr, ce problème n'est pas quelque chose qu'un novice comme moi peut expliquer clairement. Aujourd'hui, je vais parler de la façon dont je le traiterais si l'encapsulation était envisagée.

angularjs fournit un service http, qui est utilisé pour gérer les requêtes Ajax. Ici, je suppose que le lecteur connaît Angularjs, alors allez directement au sujet : comment gérer la demande de publication Encapsulation. Tout d'abord, je dois déterminer une chose, si je peux exclure les besoins personnalisés (situations qui nécessitent un traitement particulier) de tous les utilisateurs (membres de l'équipe de projet). Si je ne peux pas, alors je devrais ouvrir l'interface pour restaurer la demande de publication, j'ai donc besoin d'une sortie pour renvoyer http.post().

Le deuxième point est que je dois considérer la façon dont chaque utilisateur gère le résultat lorsque la réponse arrive. Pour les situations de réussite et d'erreur, je dois leur fournir une entrée dans la logique de traitement.

Sur la base des deux points ci-dessus, j'ai une idée. Je dois définir un service (service public) et fournir une méthode myPost, dans laquelle je permets aux utilisateurs de définir des rappels de réponse, et j'autorise. leur donner plus de liberté et leur donner un message vierge (). Heureusement, js est suffisamment flexible, je peux donc l'écrire comme ceci :

service('myHttpService', ['$http', function ($http) {
  var myHttpPost = function (url, data, successFn, errorFn) {
  }
  return {
    myHttp: function (url, data, successFn, errorFn) {
      return myHttpPost(url, data, successFn, errorFn);
  }
  }
}]);

Comme ci-dessus, je renverrai la méthode définie en interne. Cette méthode permet aux utilisateurs de définir successFn et errorFn, qui sont les rappels correspondants. pour le succès et l'échec. De cette manière, les utilisateurs peuvent pré-écrire en toute sécurité la logique de traitement des données sans se soucier d'autres détails.

De plus, je permets aux utilisateurs d'obtenir un post() plus flexible, puis je l'implémente comme ceci :

var httpPromise = $http.post(url, data, {timeout: 30000});
if (!angular.isDefined(successFn)) {
  return httpPromise;
}

Si l'utilisateur ne définit pas de rappel de réussite, ok Eh bien, faites comme si cette couche d'encapsulation n'existait pas. Je vais lancer post() et laisser l'appelant s'en occuper. Et si l'appelant veut le définir à l'avance, je dois gérer sa logique dans l'encapsulation :

return httpPromise.then(
    function (response) {
     if (response.status) {
      return successFn(response);
     } else {
      /*其他处理*/
     }
    },
    function (error) {
     if (!angular.isDefined(errorFn)) {
      /*其他处理*/
     } else {
      return errorFn(error);
     }
    },
   function () {
    /*无论何总情况下都应该被执行的逻辑*/
   }
)

De cette façon, l'encapsulation de http.post() fonctionne en gros. C'est fait. Il y a une chose à noter. Si j'utilise angulaire.isDefined() lors du traitement de successFn pour déterminer si le rappel a été défini par l'appelant, sinon, je remettrai les droits de traitement à l'appelant si c'est le cas. été défini, je m'en occupe en mon nom. La méthode then() est plus intéressante, car la méthode http renvoie un objet promise

Lorsque la réponse est renvoyée, la réponse peut être traitée via then(). success() et promise error() gèrent les rappels de différents états de réponse, mais then() est meilleur car il reçoit un objet de réponse complet, tandis que success() et error() analyseront l'objet de réponse. Les différences spécifiques sont les suivantes. : Vous pouvez le vérifier via la sortie de la console.

Ce qui précède est ma simple encapsulation de $http.post() Bien que ce soit simple, il suffit de faire face à la plupart des situations et conserve une méthode de traitement plus libre. Merci beaucoup d'en avoir discuté. avec moi, mes amis, j'ai beaucoup appris en discutant ensemble de cet emballage et j'espère qu'il pourra être utile à d'autres amis.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!