v3 planning

[PixievoltNo1]

There are lots of incremental improvements I could make that are individually fairly minor, but nonetheless breaking changes. I'd like to release a v3 that takes care of the lot of them at once. This is your chance to leave feedback on them and steer v3 towards being the best release it can be!

Updated browser/manifest version requirements

To take advantage of the latest browser developments to shrink the package, only the following will be supported:

• Chrome >=88 with manifest v3
• Firefox >=101 with manifest v2 or v3

As usual, I'll accept issues and PRs concerning other browsers, but won't test with them.

It is assumed that with Chrome's support for manifest v2 phasing out, and Firefox 102 being the latest ESR, that supporting earlier versions is of little benefit.

onWrite method replacing onSetError option

I see issue #1 get some upvotes, so I'll go ahead and implement notifications for storage writes. As there are multiple use cases for this that shouldn't all have to be written in one place, I'll switch from a callback option to a store group method that accepts a subscriber and returns an unsubscriber. Each subscriber will be called with these parameters whenever StorageArea.set is called:

1. A Promise representing the set in progress, resolving to true when it completes, or rejecting with an {error, setItems} object (the same two values currently passed to onSetError.
2. A setItems object, same as onSetError currently receives.

Additionally, said Promise is produced whether there are subscribers or not, which gives you the option of handling errors with addEventListener("unhandledrejection"). If you use neither to handle errors, you'll see an unhandled rejection in your console (this replaces the default onSetError handler).

Improvements to storageArea

storageArea will become the new 1st parameter (moving keys to 2nd), because it's better to be explicit about which area you're using. To keep this from getting verbose, storageArea will additionally accept the name of an area in chrome.storage by string:

var storeGroup = webextStorageAdapter("sync", myKeys);

~~By renaming storageArea to area and optionally accepting the name of an area in chrome.storage by string, I can support shorter, more elegant code: let storeGroup = webextStorageAdapter(myKeys, {area: "local"});~~

Changes to non-live store groups

After the above changes, live would be the only option left, and I don't think it's worth keeping when there's the unLive method. To keep creation of a non-live store group a one-line operation, I'll have unLive return the store group:

var storeGroup = webextStorageAdapter(area, keys).unLive();

Third-party areas must return Promises

I plan on modernizing the code to rely exclusively on Promises instead of callbacks to interact with extension APIs, which of course means third-party StorageArea objects must follow the same API. This will break compatibility with v0.0.4 of the long-abandoned chrome-storage-largeSync package.

Changing what re-entered values get written

It's been a quirk of the package that if you set a store to a value it already had, it gets written to storage anyways. I can reduce the amount of code by rewriting the package to use store subscriptions to collect values to write, which means storage will only be written when subscriptions get notified (i.e. when you set a different primitive value, or any non-primitive value).

Release plan

I'll allow at least two weeks for feedback, then likely publish a preview release, with the final v3.0.0 published to the npm default @latest tag no later than the end of the year ~~November 20, the anniversary of v2's release~~.

[PixievoltNo1]

I've been thinking about the storageArea parameter, and thinking I can do better than just shorten the name.

The nice thing about parameters on an options object is they don't have to be specified - but wouldn't it be better to be explicit that you're using chrome.storage.sync instead of some other area? And with the new "specifiy the area name as a string" feature, that can be expressed quite concisely. And so I'm now planning on making storageArea the new 1st parameter (moving keys to 2nd). Consumers who need sync storage would have to add "sync", , which is only 8 characters, counting the space.

Between that and the new onWrite method, this would leave live as the only option parameter. Consumers who don't want live updates can use the unLive method, so the only use case that specifically needs live: false is using a 3rd-party area that doesn't support live updates - but 3rd-party areas in general seem to be few and far between, and even then you could monkey-patch in an onChanged with no-op methods. So I think v3 will have no need for an options object.

[PixievoltNo1]

v3 releasing on v2's anniversary won't happen due to meatspace interference, but in the meantime I've updated the first post with my current plans, including my new idea of having unLive return the store group.

[PixievoltNo1]

Turns out Manifest V2's phaseout has been postponed indefinitely, and there may in fact be a need for an options parameter, so the plans for v3 have been scaled back significantly. Nonetheless, I still feel it's worth making a v3 just to switch to onWrite and require modern features that will shrink the package. Updated plans are above.

[PixievoltNo1]

The first beta has been released! See the first post for more info.

[PixievoltNo1]

v3 is released! 🎉