ngResource does not apply request interceptor #5146
Comments
|
the documentation of http://docs.angularjs.org/api/ngResource.$resource specifies |
|
Hi, |
|
Is there any plunker example I can start with? I can't see any plunker in the documentation of $resource to start with... |
|
Sorry, you have to start your own... But you can start with another example, e.g. for |
|
No response from OP, so I'm going to close this one out. |
|
Why? It's still a valid concern/bug. |
|
If you provide a plunker demonstrating the issue, then I will reopen. |
|
here you go http://plnkr.co/edit/WAd11CG7GvBWDSXkLKRh |
|
The code works as documented, so this isn't a bug. I'll open it back up as a feature request. |
|
Any reason ngResource doesn't make use of request interceptors on the As a feature request, this certainly gets my vote |
|
+1 for the feature request |
|
+1 for the request |
|
proper interceptors can't really be supported without a major refactoring of $http, because interceptors for $http are setup during configuration, not per-request. If it were going to be possible, would the $resource request interceptor run before, or after, the pre-configured interceptors? Neither would work for everybody. Providing an option to transform the request could be doable, but it would look very different from $http interceptors, so it might be problematic to make them look like they were one in the same. Looking at the history, I don't see where transformRequest was ever supported in resource before, though, so I'm not sure if we ever had a good reason to remove it, if it was ever there to begin with. |
|
👍 This would be great feature added. I need this to convert query params from camel case to snake case, per request. I can't do it with |
|
@jtheoof, why can't you do it with |
|
Because In the Prints out: The query params are gone, no way to do anything with it. |
|
How are you setting the query params ? |
|
In the service. Our backend only supports snake case, but our jshint rules are not happy about it. So I would like to create a transformer but In |
|
@jtheoof, I see what you mean. (Although, it sounds much simpler to fix the jshint rules, than adding an interceptor.) It is probably not the case, but if the query params where fixed, you could do: var ObjectsSource = new $resource('/some/url?id=:id&id_type=:idType', ...); |
|
Good point, but they are not fixed... In my opinion, |
|
FYI, it's undocumented but each action config can add the |
|
+1 for this feature request. In my case, I need to fetch a token (which may or may not be cached) from a 3rd party REST service and send it with each request made by the resource. Intercepting the request seems like the obvious answer. |
|
+1 for this feature request |
|
+1 |
|
+1 |
|
@qstrahl just FYI, but what you're trying to achieve does not depend on this non-existent feature but can be achieved via $httpProvider.interceptors.push(
($injector, $q) => {
return {
request(config) {
$injector.invoke((UserService) => {
config.headers = config.headers || {};
config.headers['x-token'] = UserService.getToken();
});
return config;
}
};
}
); |
|
@gitnik You misunderstand my problem. Your suggestion will call the interceptor for every request ever made by |
|
Ah sorry misread some parts of your question |
|
No worries On Fri, 13 Nov 2015, 17:07 Nik Karbaum notifications@github.com wrote:
|
|
+1 |
|
You get my vote for this one +1 |
|
+1 for basic feature asked from 3 years !! |
|
+1 |
3 similar comments
|
+1 |
|
+1 |
|
+1 |
|
Will this be implemented anytime ? |
|
It will be in 1.6.x (not sure about 1.5.x). You can track #13273 as well. |
|
@gkalpak That's awesome to hear, big thanks to everyone involved :D |
…ptors This patch adds `request` and `requestError` interceptors for `$resource`, as per the documentation found for `$http` interceptors. It is important to note that returning an error at this stage of the request - before the call to `$http` - will completely bypass any global interceptors and/or recovery handlers, as those are added to a separate context. This is intentional; intercepting a request before it is passed to `$http` indicates that the resource itself has made a decision, and that it accepts the responsibility for recovery. Closes angular#5146
…ptors This patch adds `request` and `requestError` interceptors for `$resource`, as per the documentation found for `$http` interceptors. It is important to note that returning an error at this stage of the request - before the call to `$http` - will completely bypass any global interceptors and/or recovery handlers, as those are added to a separate context. This is intentional; intercepting a request before it is passed to `$http` indicates that the resource itself has made a decision, and that it accepts the responsibility for recovery. Closes angular#5146
…ptors This patch adds `request` and `requestError` interceptors for `$resource`, as per the documentation found for `$http` interceptors. It is important to note that returning an error at this stage of the request - before the call to `$http` - will completely bypass any global interceptors and/or recovery handlers, as those are added to a separate context. This is intentional; intercepting a request before it is passed to `$http` indicates that the resource itself has made a decision, and that it accepts the responsibility for recovery. Closes angular#5146
…ptors This commit adds `request` and `requestError` interceptors for `$resource`, as per the documentation found for `$http` interceptors. It is important to note that returning an error at this stage of the request - before the call to `$http` - will completely bypass any global interceptors and/or recovery handlers, as those are added to a separate context. This is intentional; intercepting a request before it is passed to `$http` indicates that the resource itself has made a decision, and that it accepts the responsibility for recovery. Closes angular#5146 BREAKING CHANGE: Previously, calling a `$resource` method would synchronously call `$http`. Now, it will be called asynchronously (regardless if a `request`/`requestError` interceptor has been defined. This is not expected to affect applications at runtime, since the overall operation is asynchronous already, but may affect assertions in tests. For example, if you want to assert that `$http` has been called with specific arguments as a result of a `$resource` call, you now need to run a `$digest` first, to ensure the (possibly empty) request interceptor promise has been resolved. Before: ```js it('...', function() { $httpBackend.expectGET('/api/things').respond(...); var Things = $resource('/api/things'); Things.query(); expect($http).toHaveBeenCalledWith(...); }); ``` After: ```js it('...', function() { $httpBackend.expectGET('/api/things').respond(...); var Things = $resource('/api/things'); Things.query(); $rootScope.$digest(); expect($http).toHaveBeenCalledWith(...); }); ```
…ptors This commit adds `request` and `requestError` interceptors for `$resource`, as per the documentation found for `$http` interceptors. It is important to note that returning an error at this stage of the request - before the call to `$http` - will completely bypass any global interceptors and/or recovery handlers, as those are added to a separate context. This is intentional; intercepting a request before it is passed to `$http` indicates that the resource itself has made a decision, and that it accepts the responsibility for recovery. Closes angular#5146 BREAKING CHANGE: Previously, calling a `$resource` method would synchronously call `$http`. Now, it will be called asynchronously (regardless if a `request`/`requestError` interceptor has been defined. This is not expected to affect applications at runtime, since the overall operation is asynchronous already, but may affect assertions in tests. For example, if you want to assert that `$http` has been called with specific arguments as a result of a `$resource` call, you now need to run a `$digest` first, to ensure the (possibly empty) request interceptor promise has been resolved. Before: ```js it('...', function() { $httpBackend.expectGET('/api/things').respond(...); var Things = $resource('/api/things'); Things.query(); expect($http).toHaveBeenCalledWith(...); }); ``` After: ```js it('...', function() { $httpBackend.expectGET('/api/things').respond(...); var Things = $resource('/api/things'); Things.query(); $rootScope.$digest(); expect($http).toHaveBeenCalledWith(...); }); ```
ngResource removed transformRequest support but does not apply interceptor.request provided in actions. Shouldn't it?
The text was updated successfully, but these errors were encountered: