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

@dmurph Thanks for the very thoughtful response; we appreciate giving this idea some consideration. You raised some great points which we discussed in brief in today's call:

> So questions:
>   Is the system state / storage system operation differences worth it to unify the observer object?

Possibly, but given your third point, we don't tend to think that use-cases would cause code patterns to be the same across these storage types...

> Would it be weird to have different options for different calls to the .observe method?

It might be a little weird, though MutationObservers have options that only apply to certain types of mutations (e.g., the `attributeOldValue`, `characterDataOldValue`, and `attributeFilter` are all pretty specialized). So this point doesn't sway us one way or the other.

> Do we want it to be possible to have the same callback be called for localStorage and IndexedDB changes?

This is where it start to seem apparent that unifying these two storage types may not make the best sense--it's hard to imagine common scenarios using one callback to handle both IndexedDB and localStorage in one shot. Primarily for this reason, we think that a unified approach may not be the best fit.

> How would the changes dictionary support holding information for different storage systems, especially for specializations like IDB's transaction option?

Great question.. ?

We filed a follow-up issue on our repo to track this (#210). Otherwise, thank you for requesting a TAG review, we hope we've been helpful.


-- 
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-340807073