Customizing key used for memoization

[jedwards1211]

The array/list selectors in this package have a problem: if you splice in some elements at index n, you lose all the memoization for everything that came after n.

Edit: now that I glanced at the code I see you have an optional undocumented equalityCheck argument. In a lot of cases it's probably more straightforward to just use a function that determines the cache key for a given element.

But often it's common to have an array of objects containing a property that can act as a key:

[
  {id: 1, name: 'Andy'},
  {id: 2, name: 'John'},
  {id: 3, name: 'Martha'},
  ...
]

In this case if I could just provide a function that tells createArraySelector to use element.id as the key, then the results for each id would stay memoized no matter how the array was shuffled.

One way to do this would be to provide a keyBy option with the signature (value, originalKey) => newKey:

createArraySelector(
  state => state.users,
  state => state.multiplier,
  (user, multiplier) => user.age * multiplier,
  {keyBy: user => user.id}
)

[heyimalex]

In a lot of cases it's probably more straightforward to just use a function that determines the cache key for a given element.

Eh, it's kind of nuanced. I don't have any usage stats to support this, but I imagine that the common case is that the objects in the array are immutable. When that's the case, keying the elements doesn't achieve much, since most elements stay referentially equal across calls.

Not that I'm shutting this down, just discussing. Here's a proof of concept that I think would work.

export const keyedArrayMemoize = (fn, {equalityCheck, keyBy}) =>
  memoizeMap(fn, {
    unique: true,
    equalityCheck,
    mapper(rows, callback) {
      return rows.map(v => callback(keyBy(v), v));
    }
});

[jedwards1211]

Yeah that's a good point.

I came to this library from code I had written to manually instantiate and apply a rather complex selector to each value in an array, and I get some benefit from applying the previous selector for a given key if the value for that key changed but none of its contents relevant to the selector changed (assuming a way to create a custom selector for each key were provided by this library).

However, after converting that selector to an unmemoized function and using it with reselect-map, I don't seem to have any performance problems, so it's debatable whether it's worth the extra complexity in most cases.

[heyimalex]

Yeah, composition with caching is hard in general. I'll leave this issue open in case anyone else is interested in a similar thing, but probably won't move forward since the current code handles the common case well enough.

[heyimalex]

Actually I like zero open issues ahahahahahahahahahahahaha