I would strongly urge you to not try to hide promises, and return promises throughout. Using promises completely decouples you from whether something is synchronous or asynchronous behind the scenes. I often even return promises from services that don't do `$http` calls or are otherwise asynchronous. This allows me to later change to asynchronous calls without changing any of the code that calls my service.
On Thursday, January 2, 2014 11:06:48 AM UTC-8, Anthony Kerz wrote: > > hey, > > trying to get a grip on encapsulating calls for remote data (via $http, > $resource, or otherwise) into services. > > my initial thought was to try and have the service hide the fact that > promises may or may not be used under the hood, > but surveying the current landscape, i see promises being exposed more > often than not. > > generally, i would like to arrive at a consistent idiom for returning > elements from services, > one that has a good chance of withstanding the test of time and remaining > backwards compatible > should the need arise to swap out the underlying implementation. > > so, basically my question is: what do people think of consistently > returning promises from service calls? > > i.e. are promises so intrinsic to angular that it's a comfortable design > pattern? > > regards, > tony. > -- You received this message because you are subscribed to the Google Groups "AngularJS" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/angular. For more options, visit https://groups.google.com/groups/opt_out.
