This repository has been archived by the owner on Apr 12, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 27.4k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
feat($resource): expose promise based api via $then and $resolved
Expose $then and $resolved properties on resource action return values which allow checking if a promise has been resolved already as well as registering listeners at any time of the resource object life-cycle. This commit replaces unreleased commit f3bff27 which exposed unintuitive $q api instead and didn't expose important stuff like http headers.
- Loading branch information
Showing
2 changed files
with
238 additions
and
64 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dba6bc7
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice feature, thank you! That said, why not expose a real (derived) promise? It would be much easier to use in
$routeProvider.when({resolve:{..})
clauses for example. Currently I need to wrap the provided $then function, but it's not as great as it could be:The $promise would then return data object on success, augmented with $http - original result from $http with http status, headers, etc.
Also, I would suggest moving $resolved property to the generic
promise
interface in $q, along with thethen
- isn't it general enough for it?dba6bc7
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with most of the suggestions. the reason why we ended up with $then was to allow easy chaining of resource requests
resource1.$then(function(response) {})
.It totally makes sense to expose the whole promise though especially for the use with $route. Would you like to send a PR which would expose $promise in addition to the $then?
with regards to exposing $resolved or just
resolved
on the promise api - I'm not sure if that buys you that much. what is the use case? to access the value you'd still make an async call, so you can't really do much with that info. but maybe I'm missing something.dba6bc7
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've created #2060 to continue discussion)