Open kuza55 opened 9 years ago
Adding options to localstorage-down is one way to do it, but I actually designed this module to be easily extendable. If you look at localstorage-core.is, you can see that the actual localStorage code is quite isolated. In fact this module has already been forked a number of times due to that (async storage down, couchdown).
Why not fork this and make a safari-extension-down? Should be fairly easy to do :)
It would be easy enough, but I think unnecessary forks are bad for discoverability and maintenance.
It seems like this is almost creating a separate plugin ecosystem based on alternate localstorage-core implementations.
Yeah, I was meaning to extract this into abstract-keyvalue-down
but never got around to it.
I disagree that forks are bad for discoverability. If you publish your thing as safari-extension-storage-down
then it is crystal clear what your module is trying to do. There are many localStorage-esque JavaScript things out there (AsyncStorage, chrome extension thingie, GlobalStorage, SessionStorage), and I don't think this module needs to handle all of them.
I'm not sure if this is the right place to be filing this bug since my real desire is to fix this for the localstorage adapter in pouchdb, but as far as I can see, this is where the real code is.
Anyway, there are probably a few objects in various environments that expose localStorage-like APIs, and it would be nice if we could write to them by passing the object in to pouchdb at db construction time.
My specific desire is to write to safari.extension.settings in a safari extension so that I don't lose data from a specific database. As per https://codereview.adblockplus.org/5732725684174848/
If making it configurable is too much of a pain, then I'd be ok compiling a custom version that uses that object, but I'd need to give it a new adapter name so that I can use it side by side with this.