feat(CacheFactory): new dispose method

[ccrowhurstram]

Calling cache.dispose will dispose of that cache removing it from the CacheFactory; any items that the cache has added to underlying storage will not be removed

[jmdobry]

Can you please explain your motivation and use-case behind this pull request? I can read the code, but I can't read your mind ;)

Also, please remove your changes to any dist/ files from the PR.

[ccrowhurstram]

Hi Jason ,

Here's my specific use case.

I'm using localStorage to persist cache items between browser sessions. My application keeps track of each cache created by persisting the cache id in a list.

I have a screen / page that allows this list of caches to be administered. Whenever a cache needs to be administered, this screen needs to create an instance of a cache using the id from the list. But this admin screen does not know exactly the options that were used to create the cache, nor should it care as it's only responsible for exposing admin related functionality.

It creates the cache using sensible safe defaults. It uses the cache to perform the admin function - for example removing expired items - and then immediately disposes of the cache.

By disposing of the cache, the rest of the application code can create the cache with the real cache options. This is only possible if the cache can be removed from the CacheFactory but not destroyed

[ccrowhurstram]

I've removed the dist/ files from the PR

[jmdobry]

Why can't the admin page just use the cache created by the application?

[ccrowhurstram]

The application might not yet have [re]created the cache when the admin page is accessed.

Just to clarify - cache(s) will likely have been created in a previous browser session. These caches are lazy instantiated by the application in the next browser session only when the user happens to browse to a particular area of the application. For examples sake lets say one such area is named the invoicing module.

The invoicing module is responsible for knowing the options required for that cache and maybe will even decorate the cache with extra functionality.

Yet the admin page is available to administer the caches even before the caches have been lazy instantiated.

Of course, if the cache has already been created by the invoices module then the admin page will simply acquire a reference to it. But if the cache is not yet created it will need to instantiate the cache itself.

It will create the cache with options that might not necessarily be the ones that the invoicing module will use. It certainly won't know about the decorations that the invoicing module might want to apply to the cache. Therefore any cache the admin page creates needs to be immediately disposed of and references to it thrown away.

C

[jmdobry]

What you've implemented seems like a code smell to me. You have multiple places where you're creating the same object, which could be error prone because the multiple places may or may not use the same config to create the cache. Also, if you need to change the config you have to change it multiple places (Shotgun Surgery).

Each one of these caches is essentially a singleton. It shouldn't matter when or what accesses it, because when the cache is accessed, the same cache should be available. So, whether your invoice module needs the cache or admin module needs the cache, when they ask for it, they should get the same cache. So your cache creation code need to be moved to a single location where the cache instance can be created before anything needs it. Often in the singleton pattern, the instance is lazy-instantiated, which is okay. The key is that there is only a single point of instantiation.