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.5k
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 instead of only $then
- Instance or collection have `$promise` property which is the initial promise. - Add per-action `interceptor`, which has access to entire $http response object. BREAKING CHANGE: resource instance does not have `$then` function anymore. Before: Resource.query().$then(callback); After: Resource.query().$promise.then(callback); BREAKING CHANGE: instance methods return the promise rather than the instance itself. Before: resource.$save().chaining = true; After: resource.$save(); resourve.chaining = true; BREAKING CHANGE: On success, promise is resolved with the resource instance rather than http response object. Use interceptor to access the http response object. Before: Resource.query().$then(function(response) {...}); After: var Resource = $resource('/url', {}, { get: { method: 'get', interceptor: { response: function(response) { // expose response return response; } } } });
- Loading branch information
1 parent
da5f537
commit 05772e1
Showing
2 changed files
with
227 additions
and
101 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
Oops, something went wrong.
05772e1
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.
What is the purpose of this change and why are multiple breaking changes being introduced? Does Angular completely eschew semantic versioning?
05772e1
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.
@bclinkinbeard We only add breaking changes to the master (1.1.x) branch. The 1.0.x branch is better if you need a stable API.
05772e1
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.
Right, but are breaking changes eventually merged back into the "stable" code line? Semantic versioning dictates that breaking changes require a major version increment, so in this case that would mean 2.x.x. I assume that is not the case here and just want to clarify.
05772e1
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.
No. These changes won't be added to 1.0.x. When we declare the current master branch stable, we will cut 1.2.0.
05772e1
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.
Where is the supporting docs for how to use this now?