This would be an alternative approach to #132 - and adds a second implementation of Cache that only allows object keys and is based on WeakMap, with automatic cleanup.
I tried integrating it with the original Cache at first, but it
made the implementation hard to reason about
changed the public api of Cache (there cannot be a guarantee that dispose is called with a key!)
felt a lot less intentional - it would end up as a cache that accepted both strong and weak keys, which could invite bugs in downstream code. I prefer this option of a "deliberately weak-only" alternative implementation.
The new WeakCache would be incredibly useful in Apollo Client in multiple places, and could also be plugged in quite a lot of our wrap usages.
This implementation polyfills WeakMap with Map and FinalizationRegistry and WeakRef with dummy functions, so it will work in e.g. React Native, but it won't collect weak values.
I haven't finished tests on cleanup behaviour yet, as I wanted to wait for feedback if this is interesting at all first.
For review purposes, it can make sense to look at commit 1e26a2c0695d9ba9af488042728f5d69a724f4af independently - the first commit in this PR only copies over the existing Cache, so it adds a lot of clutter.
This would be an alternative approach to #132 - and adds a second implementation of
Cache
that only allows object keys and is based onWeakMap
, with automatic cleanup.I tried integrating it with the original
Cache
at first, but itCache
(there cannot be a guarantee thatdispose
is called with akey
!)The new
WeakCache
would be incredibly useful in Apollo Client in multiple places, and could also be plugged in quite a lot of ourwrap
usages.This implementation polyfills
WeakMap
withMap
andFinalizationRegistry
andWeakRef
with dummy functions, so it will work in e.g. React Native, but it won't collect weak values.I haven't finished tests on cleanup behaviour yet, as I wanted to wait for feedback if this is interesting at all first.
For review purposes, it can make sense to look at commit 1e26a2c0695d9ba9af488042728f5d69a724f4af independently - the first commit in this PR only copies over the existing
Cache
, so it adds a lot of clutter.