Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a possibility to delete all reselect selectors stored in the cache under a specific key pattern #40

Closed
drgarlic opened this issue Apr 23, 2018 · 4 comments

Comments

@drgarlic
Copy link

drgarlic commented Apr 23, 2018

Hi,

I have a problem with the way we can remove selectors from a cache object.

For example, in my code, the keys under which my selectors are stored, are generated using a function and are following a specific pattern (number(:number)*). I would like to remove from the cache every selector stored under a key starting with a "1".
The problem is, that I cannot use selector.getMatchingSelector because it uses the resolver instead of directly checking if _cache has a selector stored under a specific string.

I found a way to counter that by adding this function to the createCachedSelector function:

selector.getCache = () => {
      return cache._cache;
};

and by removing manually in my code every selector stored under a key starting with a "1".
But it would be much cleaner if something similar was implemented directly in your cache objects.

So my question is the next, would it be possible to add a function which removes all the selectors of a cache object that are stored under a specific key pattern ?
If not, could you at least add a function to createCachedSelector which allows us to get the _cache of a cache object (like the one I had to add).

Feel free to let me know, if I'm not being clear enough !

@toomuchdesign
Copy link
Owner

Hi @gawlk !
I think selector methods should interact with the cache by providing selector arguments but not directly the resulting cacheKey. For this reason I wouldn't add any other special method to interact with the cache but I'd go for directly exposing the cache object.

It could be a viable option for a next release.

We might consider to expose a getter as you suggest or simply expose the cache object as a property:

selector.getCache();  // as getter
selector.cache;       // as property

In the meanwhile there is another solution to let you not use a patched version of re-reselect.

From version 1 you can provide a custom cacheObject on selector initialization. Therefore you could:

  1. extend one of the provided cacheObjects with the special cache clearing method:
import {FlatObjectCache} from 're-reselect';

export class CustomFlatObjectCache extends FlatObjectCache {
  superCacheDeletion() {
    //...
  }
}
  1. provide it as a custom cache object keeping a reference pointing to it for later use.
import createCachedSelector from 're-reselect';
import CustomFlatObjectCache from './CustomFlatObjectCache';

const myCacheObjectInstance = new CustomFlatObjectCache();
const mySelector = createCachedSelector(
  // ...
)(
  resolverFunction,
  {
    cacheObject: myCacheObjectInstance,
  }
);
  1. call the custom cacheObject method whenever you want
myCacheObjectInstance.superCacheDeletion('foo');

Could it work in your use case?

Greetings!

@drgarlic
Copy link
Author

drgarlic commented Apr 25, 2018

That's great, both exposing a getter or the cache object as a property would work for me !
Any idea when the next release will be out ?

I'll your try your temporary solution and I'll let you know ! But from the looks of it, it should work.

Thank you very much !

EDIT: It works ! Should I close the issue or wait until you release the next version (with the getter) ?

@toomuchdesign
Copy link
Owner

Glad to hear that!
Let's keep this ticket open until the new release.

Greetings!

@toomuchdesign toomuchdesign mentioned this issue May 1, 2018
2 tasks
@toomuchdesign
Copy link
Owner

Shipped! v2.1.0 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants