Re: [w3ctag/design-reviews] Review request for IndexedDB Observers (#189)

I think that is interesting too. There are definitely going to be similarities if an observer was created for LocalStorage/SessionStorage/IndexedDB, but I'm unsure if the different background states / operational aspects are going to confuse developers, so this is actually a great question for you all!

Here is what would be the same:
* The observer construction (w/ calback)
* a .observe call, with options (note - options would now vary depending on storage system observing)

Differences:
* some observation options
  * indexeddb has some very specific options to facilitate complex use cases, like including a transaction, that don't really apply to localStorage, and localStorage / sessionStorage might want batching options that don't work with IndexedDB.
  * Other options like excludeValues would be fine for both.
* Consistency during change callback
  * IndexedDB Observers guarantees, with the transaction, that you can read in a consistent state where no new changes have been applied.
  * LocalStorage / sessionStorage doesn't have this idea explicitly, and I'm not sure what complications might arise here. If we're doing everything on one thread, then I guess we can't receive changes during our callback execution... @mek for whether this would be easy, or whether this is how it would work today anyways
* Intent behind group of changes
  * IndexedDB groups changes by transaction, exactly mirroring how the changes are applied by the developer. Very 1:1 easy reasoning about the changes, and allows data consistency guarantees.
  * LocalStorage and SessionStorage would probably group changes in batches (similar to cookie observer) where it waits for groups of changes, has some sort of max time / max operations, etc.
* Storage state in between change calls
  * IndexedDB is explicitly transaction-based in the changes, so before a transaction commits, those changes are not visible anywhere. The observer gets called right away when the transaction commits, and can react accordingly.
  * Local/session Storage would probably do batching for the observer, and thus the storage state could be changing before the observer is actually called. Not a bug or anything, just different.


Other things to think about:
- We already have events for local storage changes - but there is no batching here, so observers could improve performance for high-frequency changes.
- Do we want local storage observer support for ServiceWorkers? If so, we might want to go the route of cookies - although the implementation / api would probably be much simpler because it's origin scoped and not crazy-magic-scoped. Another question about whether sessionStorage is a thing for serviceworkers

So questions:
- Is the system state / storage system operation differences worth it to unify the observer object?
- Would it be weird to have different options for different calls to the .observe method?
- Do we want it to be possible to have the same callback be called for localStorage and IndexedDB changes?
- How would the changes dictionary support holding information for different storage systems, especially for specializations like IDB's transaction option?

My vote would be to either create separate observer object but keep the same pattern, or if we want to support batched observation of localStorage/sessionStorage on ServiceWorkers then we would need to explore an event-based solution.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/189#issuecomment-337401172