I've implemented a cacheService that has method get(url) which gets the value from HTTP, puts it to localStorage and returns $q promise. On the next .get(url) run it gets value from localStorage and returns it wrapped with $q.
function get(url){
var saved = JSON.parse(localStorage.getItem(url));
if (angular.isObject(saved)){
return $q.when(saved);
}
return $http.get(url).then(function(xhr){
localStorage.setItem(url, JSON.stringify(xhr.data));
return xhr.data;
});
}
Here's a case when my method doesn't work - it makes more than 1 HTTP request.
If I call cacheService.get(url) twice (e.g. from different modules):
when it runs first time, it doesn't find cache value in localStorage and makes the HTTP request
when it runs second time just after first one, first HTTP request isn't done yet and it's result value isn't cached yet. So my method makes HTTP request second time.
And I don't like it.
So the question is:
how to syncronise requests by url to have only 1 request per url?
UPD:
I've got an idea:
define var currentRequests = {};
if localStorage has cached value, return the one
if currentRequests[url] is empty, do the request and set currentRequests[url] = $http.get(url) - store the promise in
if currentRequsts[url] isn't empty, then this request is running now, then just return currentRequests[url];
As JS is run in a single thread in browsers, currentRequests is thread-safe. But it isn't in nodejs. Correct?
What do you think about it?
It might be not that good solution. but you can give it a try.
I'll suggest you to maintain the array of promises.
var promiseArr = [];
function get(url){
var saved = JSON.parse(localStorage.getItem(url));
if (angular.isObject(saved)){
return $q.when(saved);
}
//check if $http request for the url has a pending promise.
if(!promiseArr.hasOwnProperty(url)){
promiseArr[url] = $http.get(url).then(function(xhr){
localStorage.setItem(url, JSON.stringify(xhr.data));
delete promiseArr[url]; //Delete the promise once resolved.. please check.
return xhr.data;
});
}
return promiseArr[url]; //return the promise from the array.
}
Related
Here is a Promise:
var getVersion = new Promise(function(resolve){
getVersionAsyn(resolve);
});
Then a lot of http requests depend on that 'version' and the requests send in the same time.
When page initial, a lot of http requests will send to server and the request are depend on 'version'.
How to prevent getVersion promise run multiple times?
All right. I down vote myself. Such a idiot question.
How to prevent getVersion promise run multiple times?
You are already caching the promise and thus the resolved value of the version so getVersionAsyn() only ever gets called once. You can have as many .then() handlers as you want on a promise and all the subsequent once do is just fetch the saved, resolved value out of the promise data structure. They don't "execute" anything else over and over again.
The way this code works:
var getVersion = new Promise(function(resolve){
getVersionAsyn(resolve);
});
getVersion is a promise and you are already storing it. You can have as many callers as you do this:
getVersion.then(function(version) {
// access the version here
});
And, getVersionAsyn() will only ever be called just once, the first time. From then on, once the promise has resolved, you will just be accessing the saved resolved value (essentially an automatic cache). It is actually a nice design pattern to use promise for caching and async-retrieved value.
Keep the result of the getVersion in the execution context of the subsequent promises...
getVersion.then(version => {
var reqA = doHttp(version, "request A");
var reqB = doHttp(version, "request B");
var reqC = doHttp(version, "request C");
return Promise.all([reqA, reqB, reqC]);
});
Consider the following:
A web application that can have up to 100 concurrent requests per second
Each incoming request currently makes a http request to an endpoint to get some data (which could take up to 5 seconds)
I want to only make the http request once, i.e. I don't want to make concurrent calls to the same endpoint as it will return the same data
The idea is only the first request will make the http call to get the data
While this call is 'inflight', and subsequent requests will not make the same call and instead 'wait' for the first inflight request to complete.
When the initial http request for data has responded, it must respond to all calls with the data.
I am using Bluebird promises to for the async function that performs the http request.
I would like to create/use some sort of generic method/class that wraps the business logic promise method. This generic method/call will know when to invoke the actual business logic function, when to wait for inflight to finish and then resolve all waiting calls when it has a response.
I'm hoping there is already a node module that can do this, but can't think of what this type of utility would be called.
Something similar to lodash throttle/debounce, but not quite the same thing.
I could write it myself if it doesn't exists, but struggling to come up with a sensible name for this.
Any help would be appreciated.
You can implement a PromiseCaching, like:
module.exports = function request(url) {
if (caches[url]) return caches[url];
var promise = req(url);
return (caches[url] = promise);
};
var req = require('');
var caches = {};
EDIT:
Let me be more explanatory:
Here is not about caching of the responses, but about caching of promises. Nodejs is single threaded, that means, there no concurrent function calls, even when everything is async, at one point of time, runs only one peace of code. That means, there will be somebody first calling the function with the url y.com/foo, there will be no promise in the cache, so it will fire the GET request und will cache and return that promise. When somebody immediately calls the function with the same url, no more requests are fired, but instead the very first promise for this url will be returned, and the consumer can subscribe on done/fail callbacks.
When the response is ready and the promise is fulfilled, and somebody makes the request with the same url, then again, it will get the cached promise back, which is already ready.
Promise caching is a good technique to prevent duplicate async tasks.
A web application can only have 6 concurrent requests because that's the hard browser limitation. Older IE can only do 2. So no matter what you do - this is a hard limit.
In general, you should solve the multiplexing on the server side.
Now - to your actual question - the sort of caching you're asking for is incredibly simple to do with promises.
function once(fn) {
var val = null; // cache starts as empty
return () => val || (val = fn()); // return value or set it.
}
var get = once(getData);
get();
get(); // same call, even though the value didn't change.
Now, you might want to add an expiry policy:
function once(fn, timeout) {
var val = null, timer = null; // cache starts as empty
return () => val || (val = fn().tap(invalidate)); // return value and invalidate
function invalidate() {
clearTimeout(timer); // remove timer.
timer = setTimeout(() => val = null, timeout);
}
}
var get = once(getData, 10000);
You might also want to uncache the result if it fails:
function once(fn, timeout) {
var val = null, timer = null; // cache starts as empty
return () => val ||
(val = fn().catch(e => value = null, Promise.reject(e)).tap(invalidate));
function invalidate() {
clearTimeout(timer); // remove timer.
timer = setTimeout(() => val = null, timeout);
}
}
Since the original functionality is one line of code, there isn't a helper for it.
You can used promise for prevent duplicate request same time
Example write in nodejs, you can using this pattern in browser as well
const rp = require('request-promise'),
var wait = null;
function getUser(req, rep, next){
function userSuccess(){
wait = null;
};
function userErr(){
wait = null;
};
if (wait){
console.log('a wait');
}
else{
wait = rp.get({ url: config.API_FLIX + "/menu"});
}
wait.then(userSuccess).catch(userErr);
}
I just came across a weird situation and wasn't able to find an answer for after some searching.
I have a textbox that I'm using to allow a user to type keywords to filter table data. I have an ng-change directive on the input element which will fire this code:
return $http.get(url).then(function (response) {
return response.data;
});
All of this has worked great, until our tester just found some undesirable behavior in IE11. Here is an example of typing "M-A-T-T" into the textbox in IE10:
As you can see, each subsequent request takes longer than the first so the result of the fourth and final request is the one the controller receives.
Here is the same example of typing "M-A-T-T" into the textbox in IE11.
Inexplicably, the second request takes almost 2 seconds to complete which is after the fourth and final request completed. This results in the results from the "MA" request displaying when the user is expecting the results of the "MATT" request (which is what is currently in their textbox).
How can this be dealt with in Angular? Thanks in advance.
UPDATE
Based on frosty's response, I've implemented the following (in addition to bouncing) which works great:
var cancelDeferred;
var getUsers = function (criteria) {
if (cancelDeferred) {
cancelDeferred.resolve();
}
cancelDeferred = $q.defer();
return $http.get(url, { timeout: cancelDeferred.promise }).then(function (response) {
cancelDeferred = undefined;
return response.data;
});
};
The main challenge, actually, was handling errors when this method is called. The timeout returns an error just like a 500 would return an error. I want to ignore the timeouts and handle the actual errors. Here is my solution for that:
function onError(data, status) {
if (data.data !== null && data.status !== 0) {
//handle error
}
}
Now I'll try to figure out if there is a way to implement this promise-timing-out globally instead of having to alter a ton of $http.get() calls...
In the documentation for $http, it talks about a config object that you can pass as a second argument to the $http.get call, like this:
$http.get(url, config);
In that config, it talks about a "timeout" property that you can set. If you set that property as a Promise, then if you resolve the promise, it will abort the request. Check out the documentation for the description there.
Even if you use a debounce, you will want to use this "timeout" to abort the request.
https://docs.angularjs.org/api/ng/service/$http
So you would do something like this:
var cancelDeferred;
function makeRequest(){
if(cancelDeferred) cancelDeferred.resolve(); //when this gets resolved, the previous request will abort.
cancelDeferred = $q.defer();
return $http.get(url,{timeout:cancelDeferred.promise})
.then(function(res){
cancelDeferred = undefined;
return res;
});
}
So, you pass a promise to the .get request, inside the config object as the "timeout" property. If you resolve this deferred before the response comes back, it will abort the request.
My service needs to retrieve a value asynchronously, but once I have it, I'd like to used a cached version of the value.
When two controllers call this service, I'd expect the first one to cache the retrieved value and the second one to use the cached value, but according to the log, I never find a cached value. When this runs, I see a log message that shows the value being cached, then, when I follow an angular route to a different controller, I do not see that the service finds the cached value. Why does it not run according to my expectation**?**
angular.module('myApp.services').factory('Config', function() {
var Config = { };
Config.currentYear = function() {
if (Config._currentYear) {
// sadly, we never execute here
console.log("returning cached year");
return Parse.Promise.as(Config._currentYear);
}
return Parse.Config.get().then(function(config) {
console.log("caching year");
Config._currentYear = config.get("currentYear");
return Config._currentYear;
});
};
return Config;
});
A couple notes: (1) I named the cached attribute _currentYear, adding the underscore to avoid colliding with the function name. Not sure if I need to do that. (2) I return a fulfilled promise when the value is cached, so the function always returns a promise...also not sure if that's needed, but figure it can't hurt.
Instead of caching the data, why don't you just cache the promise and return it. When you cache the data, you are setting the data Config._currentYear only within the success callback and there are chances that other subsequent call(s) happening before the success callback is run. So you end up making the same call again. You can easily see this when you have calls made to the same service method from different controllers which are instantiated, by their presence on the same template. Caching a promise upfront will avoid these issues.
angular.module('myApp.services').factory('Config', function() {
var config; //Just use to save the promise
Config.currentYear = function() {
/*If there is already a call made before return the promise else
make the actual call and store the promise in the variable.*/
return config || config = Parse.Config.get().then(function(config) {
return config.get("currentYear");
});
};
});
Is there a way to wait on a promise so that you can get the actual result from it and return that instead of returning the promise itself? I'm thinking of something similar to how the C# await keyword works with Tasks.
Here is an example of why I'd like to have a method like canAccess() that returns true or false instead of a promise so that it can be used in an if statement. The method canAccess() would make an AJAX call using $http or $resource and then somehow wait for the promise to get resolved.
The would look something like this:
$scope.canAccess = function(page) {
var resource = $resource('/api/access/:page');
var result = resource.get({page: page});
// how to await this and not return the promise but the real value
return result.canAccess;
}
Is there anyway to do this?
In general that's a bad idea. Let me tell you why. JavaScript in a browser is basically a single threaded beast. Come to think of it, it's single threaded in Node.js too. So anything you do to not "return" at the point you start waiting for the remote request to succeed or fail will likely involve some sort of looping to delay execution of the code after the request. Something like this:
var semaphore = false;
var superImportantInfo = null;
// Make a remote request.
$http.get('some wonderful URL for a service').then(function (results) {
superImportantInfo = results;
semaphore = true;
});
while (!semaphore) {
// We're just waiting.
}
// Code we're trying to avoid running until we know the results of the URL call.
console.log('The thing I want for lunch is... " + superImportantInfo);
But if you try that in a browser and the call takes a long time, the browser will think your JavaScript code is stuck in a loop and pop up a message in the user's face giving the user the chance to stop your code. JavaScript therefore structures it like so:
// Make a remote request.
$http.get('some wonderful URL for a service').then(function (results) {
// Code we're trying to avoid running until we know the results of the URL call.
console.log('The thing I want for lunch is... " + results);
});
// Continue on with other code which does not need the super important info or
// simply end our JavaScript altogether. The code inside the callback will be
// executed later.
The idea being that the code in the callback will be triggered by an event whenever the service call returns. Because event driven is how JavaScript likes it. Timers in JavaScript are events, user actions are events, HTTP/HTTPS calls to send and receive data generate events too. And you're expected to structure your code to respond to those events when they come.
Can you not structure your code such that it thinks canAccess is false until such time as the remote service call returns and it maybe finds out that it really is true after all? I do that all the time in AngularJS code where I don't know what the ultimate set of permissions I should show to the user is because I haven't received them yet or I haven't received all of the data to display in the page at first. I have defaults which show until the real data comes back and then the page adjusts to its new form based on the new data. The two way binding of AngularJS makes that really quite easy.
Use a .get() callback function to ensure you get a resolved resource.
Helpful links:
Official docs
How to add call back for $resource methods in AngularJS
You can't - there aren't any features in angular, Q (promises) or javascript (at this point in time) that let do that.
You will when ES7 happens (with await).
You can if you use another framework or a transpiler (as suggested in the article linked - Traceur transpiler or Spawn).
You can if you roll your own implementation!
My approach was create a function with OLD javascript objects as follows:
var globalRequestSync = function (pUrl, pVerbo, pCallBack) {
httpRequest = new XMLHttpRequest();
httpRequest.onreadystatechange = function () {
if (httpRequest.readyState == 4 && httpRequest.status == 200) {
pCallBack(httpRequest.responseText);
}
}
httpRequest.open(pVerbo, pUrl, false);
httpRequest.send(null);
};
I recently had this problem and made a utility called 'syncPromises'. This basically works by sending what I called an "instruction list", which would be array of functions to be called in order. You'll need to call the first then() to kick things of, dynamically attach a new .then() when the response comes back with the next item in the instruction list so you'll need to keep track of the index.
// instructionList is array.
function syncPromises (instructionList) {
var i = 0,
defer = $q.defer();
function next(i) {
// Each function in the instructionList needs to return a promise
instructionList[i].then(function () {
var test = instructionList[i++];
if(test) {
next(i);
}
});
}
next(i);
return defer.promise;
}
This I found gave us the most flexibility.
You can automatically push operations etc to build an instruction list and you're also able to append as many .then() responses handlers in the callee function. You can also chain multiple syncPromises functions that will all happen in order.