Why does $http success doesn't return the updated promise?

Question

So I know that when calling success or error on an $http result, it will be called on the $http promise and then the original one will be returned rather than the updated one. What I truly don't understand is why?!

Currently, you can write something like:

$http(config)
  .success(function(data) { console.log(data); return 1; })
  .then(function (response) { 
    var msg = 'Hey, I am the original response, not 1, ';
    msg += 'and I can run even before success is completed. ';
    msg += 'This is nearly fake chaining...';
    console.log(msg);
  });

More coding style, is there a good reason not to replace the code here by this one?

// The util method has been put after the return
// just as the other $http internal methods
return decoratePromise(promise);

// Util method to add method 'success' and 'error'
// to a promise. This will spread the raw respons
function decoratePromise(p) {
  p.success = function(fn) {
    return decoratePromise(p.then(function(response) {
      return fn(response.data, response.status, response.headers, config);
    }));
  };

  p.error = function(fn) {
    return decoratePromise(p.then(null, function(response) {
      return fn(response.data, response.status, response.headers, config);
    }));
  };

  return p;
}

I don't really know what to think about those two methods... Is there a good reason to use them regarding this limitation?

Thanks for any info!

Check this post:http://stackoverflow.com/questions/16385278/angular-httppromise-difference-between-success-error-methods-and-thens-a - and event_jr's answer. parallel vs chained, it really makes sense — Michael Kang, Jul 09 '14 at 01:16

Mik378 · Answer 1 · 2014-07-09T01:05:23.947

For a sake of "meaningfulness":

$http.get(...).success(function(data) { ... }).error(function(data) { ... });

In this case, each function needs the original $http data, since those callbacks are totally independent each other.

More coding style, is there a good reason not to replace the code here by this one?

=> You wouldn't be able to do the code just above since it would break this independency.
Indeed, it would mean that error should have triggered only if success was triggered => perfect non-sense.

You can't do this "conditional flow" with regular "low-level" promise as distinct/explicitly as above.

Indeed, you would do:

$http.get(...).then(function(data){ whenSucceed }, function(data) { whenError });

But you will easily notice that it is exactly what the success/error code makes under the hood:
using the then(null, whenError) for a rejection and then(data) for the resolve.

In my opinion, it's a matter of taste to use one over the other.

Right! I break backward compatibility... which is super bad... I edited my code to preserve that. This way, you can write: $http.get(...).success(...; return data;).error(...).then(function (data) { /* this is really the data, no the raw repsonse */ }); — Paul, Jul 09 '14 at 01:16
Yes, your code in comment is valid and can manipulate what you call "updated" data. Personnally, I really prefer using "then" over success/error, since it's like every promise and no surprise could occur. — Mik378, Jul 09 '14 at 01:19

Why does $http success doesn't return the updated promise?

1 Answers1