Tag: javascript

Earlier I promised (ha! PROMISE!) to explain why I don’t like Angular’s $http.success() and .error() but this guy beat me to the punch:

Don’t use $http’s .success()

First, I hate anything that creates inconsistency in my code. If we use success() we’ll still have to use then() in every other place that has a promise, which makes this syntax sugar more of a cognitive leak in my opinion than anything useful.

Second, it couples your code in a subtle way – you’re telling everyone you’re actually reaching to the network to get something.

These are big issues but I think it misses the biggest one: you lose most of the Power of Promises™ by using .success().

Promises are amazing. You can use them to make async code reasonable. You can use them to compose small async bits into a functioning whole. And $http.success() throws it all away. Take a look at this code:

app.controller('MainCtrl', MainCtrl);
function MainCtrl($scope, $http) {
  $scope.started = 'Started';
  $http
    .get('http://date.jsontest.com/')
    .success(function(resp) {
      $scope.time = resp.time;
      return $http.get('http://ip.jsontest.com/');
    })
    .success(function(resp) {
      $scope.ip = resp.ip;
    })
    .finally(function() {
      $scope.finished = 'All done';
    });
}

See the issue? Here it is on Plunker – the IP address isn’t getting filled in. Why? Because you can’t chain HttpPromises together like you can real Promises. What’s actually happening on the second .success() is that it’s calling the Date service a second time! If you were reading that code would you expect 2 calls to the Date service? Here’s the same code using .then():

app.controller('MainCtrl', MainCtrl);

function MainCtrl($scope, $http) {
  $scope.started = 'Started';
  $http
    .get('http://date.jsontest.com/')
    .then(function(resp) {
      $scope.time = resp.data.time;
      return $http.get('http://ip.jsontest.com/');
    })
    .then(function(resp) {
      $scope.ip = resp.data.ip;
    })
    .finally(function() {
      $scope.finished = 'All done';
    });
}

That actually works like you would want it to. It works how Promises are supposed to work: if your .then() returns a Promise it will pass the resolved value to the next .then(). I’m not even getting into error testing. And if you were to pass that to some other system they could add to the chain however they wanted and it would Just Work™.

Then (ha! THEN!) there’s the issue of interoperability. Promises are in ES6 and anything that supports the Promises/A+ API should work together. That means Angular can create a Promise that Bluebird can wrap it in a timeout. Want to split 1 $http call into 5 $http micro-service calls because that’s the Hot New Architecture? If you were using .then() you could just wrap your calls in $q.all(), but $q.all() doesn’t have a .success() method. You lose all that power if you’re calling .success() and .error() all over the place.

So please please please stop using .success() and .error() in your Angular projects and stick to POPO: Plain ‘Ol Promise Objects.