Way to remove $promise and $resolved properties from all resource responses?

1,621 views
Skip to first unread message

jonr

unread,
Jan 9, 2014, 1:51:12 PM1/9/14
to ang...@googlegroups.com
Hi,

I'm upgrading to the latest version of angular and was wondering if there was a way to remove all $resolved and $promise properties from resource responses. I know in the migration guide it says to do this:


The only problem is I have multiple resources with multiple methods where I want this to be removed, which would make it not ideal to have to write the interceptor for every resource request I make. It would be nice if if there was a global resource interceptor like there is for http.

Thanks.

Vytautas Barkauskas

unread,
Oct 28, 2014, 12:08:22 AM10/28/14
to ang...@googlegroups.com
Hi,

I also have the same problem. I was wondering perhaps you found solution by yourself?

Michael Bielski

unread,
Oct 28, 2014, 10:23:21 AM10/28/14
to ang...@googlegroups.com
I can't speak for the OP, but we abstracted the inner workings of the $resource away by putting them into a service and wrapping every resource call in $q. Something like this:

function doSomething(){
     var defObj = $q.defer();

     var Promise = myResource.query();
     Promise.$promise.then(function(data){
         defObj.resolve(data);
     });

     return defObj.promise;
}

The end call in the controller (directive, filter, other service) just has to deal with a promise to resolve.

var serviceResult = myService.getSomething();
serviceResult.then(function(data){
     myVar = data;
});

It may not be what you are looking for, but it works for us.

Kyle Cordes

unread,
Oct 30, 2014, 10:17:19 AM10/30/14
to ang...@googlegroups.com
On Tue, Oct 28, 2014 at 9:23 AM, 'Michael Bielski' via AngularJS <ang...@googlegroups.com> wrote:
I can't speak for the OP, but we abstracted the inner workings of the $resource away by putting them into a service and wrapping every resource call in $q. Something like this:

function doSomething(){
     var defObj = $q.defer();

     var Promise = myResource.query();
     Promise.$promise.then(function(data){
         defObj.resolve(data);
     });

     return defObj.promise;
}


In this code, Promise.$promise is already a promise that resolves to the right thing. What you are getting by creating a new promise around it? You could replace the above with:

function doSomething() {
  return myResource.query().$promise;
}

This also solves the original problem, of wanting to return a promise instead of an object with $promise in it.


--
Kyle Cordes

Michael Bielski

unread,
Oct 30, 2014, 10:44:46 AM10/30/14
to ang...@googlegroups.com
Yes, we are aware of that. We did it this way so that we could do any other processing that we needed to the data before it is sent back. I should have explained that, sorry.

Kyle Cordes

unread,
Oct 30, 2014, 12:32:33 PM10/30/14
to ang...@googlegroups.com
On Thu, Oct 30, 2014 at 9:44 AM, 'Michael Bielski' via AngularJS <ang...@googlegroups.com> wrote:
Yes, we are aware of that. We did it this way so that we could do any other processing that we needed to the data before it is sent back. I should have explained that, sorry.


It certainly works to make the new promise as you did in your example. I believe the more idiomatic way to post processed the data using promises is to chain it more like this though.

function doSomething() {
  return myResource.query().$promise.then(data) {
    return someProcessingOf(data);  // gets wrapped for you.
  };
}

I don't mean to sound like I'm saying how the code has to be written. It is an API, it can be used in 1000 different ways. I've just made it my personal mission to notice when people are needlessly writing extra lines of code around promises, and to point out how changing works so that they can use it if they like :-)

Michael Bielski

unread,
Oct 30, 2014, 1:10:05 PM10/30/14
to ang...@googlegroups.com
Hmm... you do make a valid point. The only argument that I could even try to put up would be readability, and even that is a weak one. I'll have to look at doing it that way and see where else we can make improvements. Thanks Kyle.
Reply all
Reply to author
Forward
0 new messages