I'm trying to use angulars $http, with both a cache and an interceptor.
The quick question:
Currently when angular gets the answer from the server, it first caches it, and then it passes it through the interceptor.
Is it possible to force angular to first pass it through the interceptor and only then cache it?
The long issue:
The server responds every call with a format similar to:
{permission: BOOL, data:[...]}
In the interceptor response I check the permission, and if correct I throw it away and pass only the data field to the application level. If it fails I reject and popup an error, etc... (Maybe I should do it in a transformResponse function, but I'll endup facing the same issue).
Then for some API calls I'm requesting a bunch of resources like that:
/resource/ALL
And it obviously caches this request and answer, but what I want to do next is fake caching every resource that I received.
So forthcoming calls to /resource/{some resource id} are already cached, cause I've already received it in the call where I requested ALL.
The problem I'm facing is, when I want to fake cache, on the application level, I lost the "{permission: BOOL" part, cause I've thrown it in the interceptor.
Some notes:
1- Of course I could also fake the permission part, and just hardcode it, but I feel it's not an option since if I later add / modify / remove metadata it's another place I've to look at.
2- An other way would be to don't throw the metadata on the interceptor / transformResponse, but again this is not an option since I don't want to select the 'data' field every time I call $http on the application level.
So I think the best option for me would be to cache after the interceptor, and not before.
Hope I made the issue clear, and any answer is welcome!
Related
I am using with ui-route by the way
But I want to create something useful for all the site
That every time there is a request to the server
the icon will appear
You can do this a number of ways. Write an angular service that you call inside every request that sets a variable to true when a request goes out, and false when the response comes back. Then attach an ng-show to an element with the icon set to the variable.
Also you can look into the $http interceptors, which might prove useful as then you would not have to call the service for every request manually. Downside, it would trigger on every request which may not be the desired effect.
Is there a way to get the header of the current page in angularjs, without having to do a separate call? I can't find this in the docs anywhere, but it seems like it should be possible.
E.g. if the file index.html contains the angular code, how do I read the header of the initial request to get index.html? I could use $http to make the call again, but that seems unnecessary.
If you are not handling the http request you won't have access to the request or the response, unless the code that it's making the request exposes that information somehow, which is not the case. So, I'm sorry but the answer is no.
However, if I may: what is exactly what you need from the response header? Because there could be other ways to obtain the information of the headers (i.e. cookies)
I have a simple question about best practices.
A service loads once at load time.
Let's say there is a method called getUser in the service called user.
I have to call getUser in several controllers.
The GET request will happen twice right?
Is there a good practice to check whether the data has already been fetched to avoid this second call?
Yes, the call gets executed twice. You can use angular's built in $http cache option, or you could use an existing module like angular-cache, or other libraries such as Breeze or Amplify. You can also try handling it yourself, probably the worst option.
In an Angular JS app I'm working on, I am using a service to periodically (in a $timeout) make a GET request to a URL in my API (both the Angular app and the API are being served from port 5000 on localhost).
For some reason, it appears that $http is not actually sending the GET. For each $http.get(), the .error() is called with empty data and a status of 0. When I check in my server log (I'm running a Ruby on Rails backend with the Unicorn gem for my server), it appears that the server never receives the request from Angular.
Here's the function in my service:
updateUserStatus = () ->
$http.get('/api/v1/status').success (statusData) ->
# update the variable and notify the observers
this.userStatus = statusData
notifyObservers()
startStatusTimeout()
.error (error, status) ->
# if there's an error, log it
console.log 'error:'
console.log error
console.log status
startStatusTimeout()
What's really odd is that it only happens sometimes. When it stops working, I can change the URL in the $http.get() to '/api/v1/status.json', and it works. For a while. Then I switch it back and it works again, for a while... obviously there is some greater issue at play.
I've been racking my brain for a few days now, and I've seen a bunch of similar issues on SO, but they all seem to be solved with implementing CORS in Angular, which I don't think is applicable to my situation because it's all coming from localhost:5000. Am I wrong? What's going on?
For reference, I'm using Angular version 1.0.7.
I had the same problem.
Check your code to see whether this happens after events that are fired from the DOM and are unknown to Angular.
If so, you need to add $scope.$apply(); after the get request in order to make it happen.
I'm fairly new to Angular so I'm not sure this is the best practice for using Angular, but it did work in my case.
See this similar question for a better explanation.
Our server saves the model, and returns the JSON as specified in the doc. The problem is, backbone.js issues PUT as soon as it receives response. Can it be because the model is sent without _id property, and the server appends that to a model?
If you believe that Backbone automatically issues a PUT based on the response to a previous request, you are confused. Backbone does no such thing. If you a see a PUT going over the wire, something in your code base (an event binding or otherwise) is calling either save on a model or a manual sync.
Otherwise, you'll need to post code in order for us to help you debug, but I can assure you backbone itself will not ever issue a network request that is not triggered by external code through one of a very small set of methods such as fetch, save, or sync.
As to IDs on the server, that should be perfectly fine. In fact, if backbone were to get confused and think that an existing model was a new model, it would issue a POST instead of a PUT, which is not what you are seeing.