I'm using a sqlite-wasm database in localStorage created with oo1.JsStorageDb('local'); and it's working great! I haven't found an elegant solution for incoming changes from other sessions/tabs. The following seems to be working. I'm using journal_mode=DELETE and from the minimal testing I've done it seems the last storage event that happens is the journal being deleted. But hardcoding 'kvvfs-local-jrnl' seems brittle.

// listen for changes from other sessions
addEventListener('storage', (event) => {
	// when other session clears the journal, it means it has committed potentially changing all data
	if (
		event.storageArea === localStorage &&
		event.key === 'kvvfs-local-jrnl' &&
		event.newValue === null
	) {
		// load data from other session
	}
});

Is there a better way?

Kind regards Søren

Dear Stephan

Thank you very much for your kind response.

I agree that firing a custom event on JsStorageDb would be nice.

I was mainly using localStorage for a blog post where I implement TodoMVC using sqlite-wasm, so it's not a great concern for me.

You can try it out(it has a live SQL console) and read about it here: http://zoren.dk/todomvsqlite.html

/Søren

I agree that firing a custom event on JsStorageDb would be nice.

In hindsight, my only concern with that is that it's far removed from the rest of the API, so seems a bit like a back door. How about if, instead, we add something like:

sqlite3_js_kvvfs_onSOMETHING( callback )

where SOMETHING is a to-be-determined appropriate name (feel free to suggest something) and callback is a function which receives:

{
  target: localStorage|sessionStorage
  ... maybe other info? Any suggestions?
}

We could implement that in terms of an event listener, but i'd prefer to make it part of the visible API rather than hiding it entirely behind an event listener.

I don't think this is the right approach. Your todo app knows exactly when it modifies the database, so it can easily notify other instances at the application level (I would use BroadcastChannel, but you could use an application-specific localStorage key if you want the same browser compatibility). Getting reactivity from the database might be a cool feature but I don't think it's needed here.

(I would use BroadcastChannel, but you could use an application-specific localStorage key if you want the same browser compatibility)

@Søren FWIW, i'd trust Roy's intuition on that over my own! He's far more in touch with modern JS than i am. i'll hold off on adding an event handler to the library for now.

Thank you both very much. I've updated the blog and code to use a BroadcastChannel. And it is indeed much more elegant!