1

Promise pattern method:

this.getData= function(url){
        var defer = $q.defer();

        $http({method: 'GET', url: url}).
            success(function(data, status){
                defer.resolve(data);
            })
            .error(function(data, status) {
                defer.reject(status);
            });

        return defer.promise;
    };

Calling this inside a controller -

utility.getData().then(function(){});

VS

promise = utility.getData();
promise.success(function(){})

Are they both the same?

Tisha
  • 827
  • 3
  • 11
  • 34

3 Answers3

1

Then gets second optional function parameter, first is executed on success, second on failure:

promise.then(function () {
    // success
}, function (err) {
    // error
});
karaxuna
  • 26,752
  • 13
  • 82
  • 117
1

You are making this more complicated than needs be because $http is already a promise, so you should not be using $q

this.getData= function(url){
    return $http({method: 'GET', url: url})
};


this.getData(urlToUse)
.then(function(res) {
    // do something with res.data 
})
.catch(function(err) { console.error(err); });
Simon H
  • 20,332
  • 14
  • 71
  • 128
1

As state by the Angular 1.5 document

The $http legacy promise methods success and error have been deprecated. Use the standard then method instead. If $httpProvider.useLegacyPromiseExtensions is set to false then these methods will throw $http/legacy error.

The $http service always returns promise, but prior to 1.4X you had the success and error methods that were shotcuts of the promise.then(success, error).

Besides that, the promise notation is really better because of the power of chaining promises, something that is not that elegant using callbacks notation. Something like:

utility.getData().then(function(){
    return utility.getMoreData();
}).then(function(response){
    //do something if the data from second call
}).catch(function(err){
    //something was wrong with one of the calls
});

With single calls, you may not see any advantage, but promises are really good to prevent de Callback-hell

Besides that, your utility service should return de $http promise, you don't need the $q. Something like:

this.getData= function(url){
    return $http({method: 'GET', url: url});
};

If you realy want to manipulate the data before the call, you can again use the power of promise:

this.getData= function(url){
    return $http({method: 'GET', url: url}).then(function(response){
        data = processData(response);
        return data;
    });
};

the data will be available to the then function on the caller.

Renan Ferreira
  • 2,122
  • 3
  • 21
  • 30
  • 1
    Great answer! I am actually struggling with a related issue here - http://stackoverflow.com/questions/36039450/how-can-i-call-the-second-sequential-promise-design-pattern-method-in-a-loop-in – Tisha Mar 16 '16 at 17:14
  • I edited the answer with some adjustments to your code – Renan Ferreira Mar 16 '16 at 17:18
  • The problem is really with the looping in that question. When I do a console.log(i) inside the then method, I see i value is 5, which is the max value. And so this results in only the last object of my scope array to have a value but the rest of the objects are emtpy. So does your solution solve that issue? – Tisha Mar 16 '16 at 17:24
  • What should the processData() have here? How to access promise data? The service returns an array of jsons. – Tisha Mar 16 '16 at 21:16
  • the processData() is just a function that you can create do manipulate the response of the service *before* returning it to the caller (your controller). The response of the service, the array of jsons, is in the response variable. Just to make it clear, usually you don't need to make this process, so you can just return $http(..); and process your data in your controller. This example is just for cases where your controller is expecting the data in a format different from the data returned by the service. – Renan Ferreira Mar 17 '16 at 12:19