Preventing cross-Tab state synchronisation

[Holf]

Hi,

I see this code, which propagates state changes across instances of the same app in different browsers and tabs:

svelte-persisted-store/index.ts

Lines 56 to 65 in dde5ece

	if (browser && storageType == 'local') {
	const handleStorage = (event: StorageEvent) => {
	if (event.key === key)
	set(event.newValue ? serializer.parse(event.newValue) : null)
	}
	window.addEventListener("storage", handleStorage)
	return () => window.removeEventListener("storage", handleStorage)
	}

Might you consider an option to disable this behaviour selectively control this behaviour?

I'm thinking perhaps the persisted could additionally return an updateOtherTabs(enabled: boolean), which would allow you to turn this behaviour on and off.

This flag would determine whether or not the set on line 59 is called.

Alternatively, we could have the option to pass in our own handleStorage function?

[joshnuss]

Hi Holf!

Can you explain a little about the use case where you don't want to sync across tabs?

Wouldn't you be better off with a session store in that case?

[Holf]

Hi, thanks for responding so quickly.

It is somewhat involved but, to use a similar, illustrative example:

• Say have an App with a list of 'Documents', each of which can be edited.
• State associated with a Document is held in a number of LocalStorage entries (Titlte, Content, etc):
• If the user opens a separate Tab, the in-memory (store) state of both instances of the same document remains synchronised, which is great.

However:

• I want the user to be able to edit two different documents at the same time, in two different tabs.
• In this scenario, I no longer want LocalStorage changes to propagate to other instances.
• But, if the user changes back to the same document again so both tabs have the same instance, I want state change propagations restored.

Basically, LocalStorage is great for when the documents being edited are the same.
SessionStorage is great for when documents being edited are different. 😆

I realised, after I posted the request above, that even if I were able to disable the "storage" subscription, I'd need to also handle the case where the user swaps from one document to the other and starts editing i.e. the comms channel between instances needs to be bi-directional so the 'propagate events' can be disabled in both places. And when you add more tabs to this scenario, it gets messy...

I think I may end up with:

• Active document in SessionStorage.
• Dormant documents stored as JSON blobs in LocalStorage.
• Changes propagated to other tabs via comms channel (TBC, maybe Broadcast Channel API although Safari didn't support that until quite recently) or something done via LocalStorage "storage" events... (there are a few packages already for this which I might use).

Or:

• All document state kept in LocalStorage, as the synchronisation already in place is really nice.
• Different LocalStorage key prefixes for state pertaining to different documents.

I think I'll go with the latter. The only hesitation I have is if the user has, say, 50 documents, that will be 250 or so LocalStorage entries. But, when I reflect on it further, I can't think of any reason why this is a problem; key lookup times will be trivial even if there are thousands of entries.

Anyway, thanks for the response and the consideration. Writing this out has been very helpful for me to get my own thoughts in order.

[joshnuss]

Great 👍

That clarified for me too, I guess I was driving at the issue of consistency. Disabling cross-tab sync wouldn't completely solve that.

Unless there was a CRDT or something like that, but then local storage would just be used as an offline backup. Might not even need a store.

[joshnuss]

There is now a config option to disable syncing across tabs.

See: #226