Closed RoxKilly closed 1 year ago
I cloned to open a PR and noticed that this has been fixed in the master branch. However it hasn't been released to v3
yet (v3.1.2 has the same issue). Is there a plan to release this change on the v3.x
version?
Is the intent to require users to move their codebase the v4
releases to be able to implement StoreInterface
?
I think the change is small enough that releasing it as a v3.x
would probably be worthwhile for teams that face a lot of friction whenever they want to upgrade a dependency to the next major version. That said, feel free to close the issue if upgrading to v4
is the intended fix.
Thanks
Hi @RoxKilly,
Sorry about the delay but yes, the actual fix has been done into the v4 release.
If you really need it, I can add the fix in v3 and make a new patch release.
I close this issue for now but feel free to reopen and tag me if you need it.
Steps for Reproduction
The docs suggest that the dev can use a custom store by implementing the StoreInterface. I'm working on a custom cache to use as part of the library's chain cache but one sticking point is the
Set
. Here is its definition:Option
is a function that takes and configures anOptions
object, both from the library package. here is how the library passes it to my cache's setter: githubWithin the library's cache implementations, the configured
Options
object is then read to discern, for example, the expiration date of the cache entry: exampleThe issue I face is that Options (declared here) makes all its properties private, so when I implement my own
Set()
, I have no way to read it to figure out when the cached entry should expire.How is my custom StoreInterface implementation supposed to figure out the caching options used?
Expected behavior:
Custom struct implementing
StoreInterface
can be used in the chain cacheActual behavior:
Unable to implement interface correctly because the
Options
object passed to my implementation does not expose the options in public propertiesPlatforms:
All
Versions:
v3.1.1