Provide solution similar to the storage event

[Zirro]

The specification for localStorage includes the storage event, which can be summarised by this note:

When the setItem(), removeItem(), and clear() methods are invoked, events are fired on the Window objects of other Documents that can access the newly stored or removed data, as defined in the sections on the sessionStorage and localStorage attributes.

To my knowledge it is supported by all current browsers, but I'm not sure how widespread its usage is on websites. I've used it to keep bits of data in the UI updated across tabs on a fairly large site, though.

I didn't find a previous mention here, but if this specification is intended to cover the use cases of the original localStorage it should include a similar mechanism.

[domenic]

It's unclear to me whether this is worth the extra complexity. It's good to get feedback that at least one developer has used it, but I'd like to hear from more folks, and ideally gather some usage data. (I've checked and it doesn't exist in chromestatus today.) One signal is that none of the other localStorage-but-better libraries have this ability.

Note that that you could provide the same abilities yourself using any of the other mechanisms used to broadcast application state changes, e.g. BroadcastChannel. So it's basically a matter of whether the additional complexity is justified in saving people the BroadcastChannel code. I think that hinges heavily upon usage.

[Zirro]

It's good to get feedback that at least one developer has used it, but I'd like to hear from more folks, and ideally gather some usage data.

From the discussions I came across when I first found it a few years ago, this aspect of localStorage does not seem to be widely known among web developers. It's a bit unfortunate as good use cases do exist.

On the site where I used it for example, it is common for users to open a large number of tabs - sometimes in the hundreds. With this API I could poll the server for new data in just one of them, and distribute it seamlessly to all the others.

But as you say, there's no reason I couldn't use BroadcastChannel to do the same thing these days. Except this I suppose, but that's a separate issue. I agree that the complexity from adding this might not be desirable as long as it can be implemented effectively on top of the spec implementation - perhaps by hooking onto the backingStore?

One signal is that none of the other localStorage-but-better libraries have this ability.

It doesn't appear to be widely used so that's probably another point against adding it to this specification, but I figured I'd mention that there is an extension for localForage: https://github.com/localForage/localForage-observable

If this specification advances under the name "async local storage" without this addition, I think it'd be appropriate for it to mention that it's not a goal to support every use case of the original localStorage, and potentially recommend APIs such as BroadcastChannel instead.

[SanderElias]

Hmm I have to second this issue.

While it is not really a 'known' feature to the larger developer community, it is a really nice thing to have. I have used it in a couple of situations. It is an easy and relatively 'cheap' way to communicate between different tabs of your application.
When you take this into account when you design your application, it makes areally nice user experience.
An example: imagine a dedicated browser tab to 'add items' to a collection, and update the other tabs when that happens.

[micahjon]

Just wanted to second supporting the "storage" event if possible, since it's a simple, purely client-side, cross-browser way to communicate between tabs.

I work on a relatively heavy webapp (BeFunky) for editing photos in your browser using WebGL, where we can't afford to auto-save every active instance (opened tab) of our application (b/c of the large storage requirements of photos) and use the "storage" event to ensure only a single tab is auto-saved to IndexedDB at once.

Of course, if the new async LocalStorage doesn't support this API, we can still use the old synchronous LocalStorage for it, but it is a handy feature to have built in. Just my two cents!

[domenic]

Thanks for weighing in, all. As stated above, the path we're going to take here is to allow web developers to provide the same abilities themselves, using any of the other mechanisms used to broadcast application state changes, e.g. BroadcastChannel, shared workers, etc.

If we see that pattern being used in some large percentage of uses of async local storage, then we should consider a new layered API, or addition to this one, to allow web developers to import that functionality instead of writing it themselves. But until we get a sense of the usage of such functionality, we're prioritizing the feature set we know will get usage first.

As such, let me close this, as there's nothing actionable here until we start to see async local storage usage patterns in the wild. At that time, if we see a lot of usage of async local storage + BroadcastChannel or similar, we can reopen.