Object argument not getting cached for async function? about memoizee HOT 14 CLOSED

@ecaron this is expected, in second case at all times function receives different object, therefore it's treated as different argument. Values by default are compared with === (and more precisely by this logic)

If you want to have different objects but with same structure treated as same, then you need to provide custom normalizer function that will assure that.
e.g. your example will produce cache hits, for below configuration:

var memoized = memoize(cacheTest, { async: true, normalizer: JSON.stringify });

EDIT (made after below comments):
As normalizer receives arguments object, it actually should be:

var memoized = memoize(cacheTest, { async: true, normalizer: function (args) {
  return JSON.stringify(args[0]);
} });

from memoizee.

@vekexasia can you post minimal test case that in your eyes doesn't work as expected?

from memoizee.

@vekexasia as I don't have any working test case that would replicate a problem, and I'm not aware of any issues in memoizee. I'm closing this one

from memoizee.

@medikoo, I'm guessing the issue that @vekexasia is experiencing is this has cache hits:

var memoize = require('memoizee');

var cacheTest = function(a, cb){
  console.log("Cache missed");
  return cb(null, a);
};
var memoized = memoize(cacheTest, { async: true });

var test = {a: 1};
memoized(test, function(err, res){
  console.log(res);
  memoized(test, function(err, res){
    console.log(res);
    memoized(test, function(err, res){
      console.log(res);
      process.exit();
    });
  });
});

But this one only has cache misses

var memoize = require('memoizee');

var cacheTest = function(a, cb){
  console.log("Cache missed");
  return cb(null, a);
};
var memoized = memoize(cacheTest, { async: true });

memoized({a: 1}, function(err, res){
  console.log(res);
  memoized({a: 1}, function(err, res){
    console.log(res);
    memoized({a: 1}, function(err, res){
      console.log(res);
      process.exit();
    });
  });
});

from memoizee.

(thumbsup)

from memoizee.

@medikoo But the normalizer applies to every argument in the function, rather than just limiting to the ones expected by the length parameter. So, for example, if you're using with and wanting to pass along a req-esque parameter outside the cache-specific parameters, you'll get a circular structure error.

/me works on providing an example

from memoizee.

Here's the code showing that the normalizer is getting values that I was expecting the length parameter to overlook:

var memoize = require('memoizee');

var cacheTest = function(a, req, cb){
  return cb(null, a);
};
var whatIGot = function(a){
  //I expect the normalizer to be only working on the values that the length parameter implies
  console.log(a);
  return JSON.stringify(a);
}
var memoized = memoize(cacheTest, { async: true, length: 1, normalizer: whatIGot });

memoized({a: 1}, {should: "not stringify me"}, function(err, res){
  console.log(res);
});

from memoizee.

@ecaron sorry I was not precise, what normalizer receives is arguments object of function call, and it's role is to return unique id on which bases uniqueness of arguments will be assumed.

So if you're interested only in first argument, same you're normalizer should generate id only against first one. So what I wrote, should actually be:

var memoized = memoize(cacheTest, { async: true, normalizer: function (args) {
  return JSON.stringify(args[0]);
} });

from memoizee.

@medikoo And that makes sense, but as a consumer of the library and given the explanation within https://github.com/medikoo/memoize#arguments-length, I'd expect the uniqueness of the arguments to correlate to the length desired to impact the cache strategy.

Would you consider a PR that adjusts the normalizer to rely on the length parameter if its explicitly defined?

from memoizee.

@medikoo And that makes sense, but as a consumer of the library and given the explanation within https://github.com/medikoo/memoize#arguments-length, I'd expect the uniqueness of the arguments to correlate to the length desired to impact the cache strategy.

It's normally assured, however normalizer takes original arguments object, and arguments It's the object that we should not alter in any way.

The only fix for that would be to change normalizer strategy, so instead of arguments object it will receive arguments same way as input function, so as e.g. normalizer(arg1, arg2, ...args) and in that case we could limit them against defined limit.
However this would definitely downgrade performance, firstly we would need to call normalizer with apply, and logic that would filter them against limit again will put perf down further.

So I think I would prefer to stay with what it is. It's very direct to just pass arguments over, and additionally I think it's not that big issue when you know it's an actual arguments object. Above we forgot about it, and that was the main issue.

from memoizee.

How do you retrieve data once data is cached?

from memoizee.

How do you retrieve data once data is cached?

@nguyeti In normal mode input arguments are stored in an array, which is an index mapping to result array. So knowing index of input argument you get to know index of result within result array.

from memoizee.

Thank you very much.

I noticed that the input arguments are used to identify the data in the delete method for example. But I can't find the ext Get method you and epayet exposed, how can I use it to access the result array?

from memoizee.

@nguyeti there's no direct access to cache provided. What use case you have for that?

from memoizee.