AngularJS encapsulation $ http. post () instance details, angularjshttp. post

AngularJS encapsulation $ http. post () instance details, angularjshttp. post

AngularJS encapsulation $ http. post () instance details

I used a mobile APP project not for a long time. I used the ionic + AngularJS + cordova framework. Many problems were encountered during the process. One of them was the encapsulation of Ajax.

In fact, we have never stopped talking about encapsulation issues, and different projects have different requirements. For example, when I was working on this project, I was criticized for not considering encapsulation at the beginning, but a friend of mine was criticized for encapsulation ...... It's embarrassing, isn't it.

So how should we define whether to encapsulate this question? In fact, this is not a very complicated problem. In the final analysis, it is a problem of income ratio. If the project scale is not very large, it is meaningless to consider the encapsulation problem too much, the benefits of the project are extremely low. For large projects, if they are not encapsulated, the potential risks will be much higher. Therefore, the initial investment is worthwhile.

Of course, this problem is not something that I can clarify. Today I will talk about how to deal with it if we consider encapsulation.

Angularjs provides a service http, which is used to process Ajax requests. Here I assume that the reader understands angularjs, so he goes straight to the topic: How to Handle encapsulation of post requests. First, I need to determine whether I can eliminate the Personalized Requirements of all users (project team members) (situations that require special handling ). If I cannot, I should open the interface to restore the post request, so I need an exit to return http. post ().

Second, I need to consider how each user can handle the result when the response arrives. for success and error, I need to provide them with an entry to the processing logic.

Based on the above two points, I have a general idea. I need to define a service (public service) and provide a myPost method. Specifically, I allow the user to define the callback of the response, and I allow them to get a more free processing method, and give them an original post (). Fortunately, js is flexible enough, so I can write it like this:

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

As shown above, I will return the internally defined method, which allows the user to define successFn and errorFn, that is, the corresponding Success and Failure callback, so that the user can confidently write the data processing logic in advance, you do not need to care about other details.

In addition, I allow users to get more flexible post (), So I implement it like this:

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

If the user does not define a successful callback, well, this layer of encapsulation should not exist. I will discard post () and the caller will handle it by himself. If the caller wants to define them in advance, I should handle their logic in the encapsulation:

Return httpPromise. then (function (response) {if (response. status) {return successFn (response);} else {/* Other processing */}, function (error) {if (! Angular. isDefined (errorFn) {/* Other processing */} else {return errorFn (error) ;}, function () {/* the logic that should be executed in no case */})

The encapsulation of http. post () is basically complete. Note that if angular is used when processing successFn. isDefined () determines whether the caller has defined a callback. If not, I will give the caller the processing right. If yes, I will handle it on behalf of the caller. Among them, the then () method is interesting, because the http method returns a promise object, and the response can be processed by the then () method in response to the returned result. In fact, the promise method can be used completely. success () and promise. error () is used to process callbacks of different response states, but then () is better, because it receives the complete response object, and success () and error () the response object will be parsed. For specific differences, you can use the console output.

The above is my $ http. A simple encapsulation of post () is simple, but it is sufficient to deal with the majority of cases and retains a more free way of handling. Thank you very much for your discussion with me, discussing the package together has gained a lot and hopes to help other friends.

Thank you for reading this article. I hope it will help you. Thank you for your support for this site!