0

My server always returns the data as {meta:<> , reply:<>}. so, In my angular service, I am trying just to return the reply part

Below doesn't work

function get(url) {
     return $http.get(url)
        .success(function(d){ //d {meta:<> , reply:<>}
            return d.reply
        })
}

get("/a/b/c").then(function(d){
    console.log(d) // prints server response ({meta:<> , reply:<>}); not reply
})

but, if I use $q and resolve the promise, it works. But, I thought I could use the promise retuned by $http directly. Is there a logical difference between these two? what is wrong?

function get(url) {
    var deferred = $q.defer();
     $http.get(url)
        .success(function(d){ //d {meta:<> , reply:<>}
            deferred.resolve(d.reply)
        })
    return deferred.promise;
}

get("/a/b/c").then(function(d){
    console.log(d) // prints reply part of server response
})
bsr
  • 57,282
  • 86
  • 216
  • 316

3 Answers3

1

since $http already returns promise you can do it this way:

http://plnkr.co/edit/3uiXr25RDiiKMD4eunsS?p=preview

maurycy
  • 8,455
  • 1
  • 27
  • 44
0

This is because when $http.get gets resolved, the promise completes with what is passed to the function in data. In this case the "d".

From this page: http://docs.angularjs.org/api/ng/service/$http

"Returns a promise object with the standard then method and two http specific methods: success and error. The then method takes two arguments a success and an error callback which will be called with a response object. The success and error methods take a single argument - a function that will be called when the request succeeds or fails respectively. The arguments passed into these functions are destructured representation of the response object passed into the then method."

so the then method gets the response, not what you return in success.

Mathew Berg
  • 28,625
  • 11
  • 69
  • 90
0

In your first "broken" example, the .success() isn't actually doing anything. The return value from your success callback isn't being used at all and you are still just returning the $http promise which will resolve with the entire response data (not just d.reply). If you only want to return d.reply, then your second example is the correct way to do it.

The success function itself, returns the same promise object as $http.get for method chaining. So this:

function get(url) {
     return $http.get(url)
        .success(function(d){ //d {meta:<> , reply:<>}
            return d.reply
        })
}

get("/a/b/c").then(function(d){
    console.log(d) // prints server response ({meta:<> , reply:<>}); not reply
})

is exactly the same as this:

function get(url) {
     return $http.get(url);
}

get("/a/b/c").then(function(d){
    console.log(d) // prints server response ({meta:<> , reply:<>}); not reply
})

When you execute this you are returning the return value of the call to .success() which is the original $http promise. You are not returning the return value of your callback.

return $http.get(url)
.success(function(d){ //d {meta:<> , reply:<>}
    return d.reply
})
Craig Squire
  • 2,141
  • 14
  • 13
  • I am not sure that is correct. $http.get returns a promise, that normally is chainable with .then (I suppose success is just a wrapper). so, I chain to return d.reply, that should resolve before next then call. but, I might be wrong as I can't explain the wrong behavior. – bsr Mar 07 '14 at 12:53
  • Yes, it is correct. Your get(url) function is returning the original promise way before your .success() callback is ever executed. – Craig Squire Mar 07 '14 at 12:55
  • I could see the success handler called, if I debug / put a console log. so, it is called. may be it is not resolved when I called. – bsr Mar 07 '14 at 13:09
  • It's called, but that return value isn't helping you. Read the code very carefully at what's happening here. Remember that your success callback is called *asynchronously* (when your ajax call completes). But your return of the original promise is happening *synchronously* (before your ajax call completes). How could you possibly have the ajax response at that point? – Craig Squire Mar 07 '14 at 13:22