Use localStorage to cache incidents and synchronize data across contexts

[wsanchez]

Use localStorage to cache incidents and synchronize data across contexts

We load every incident when we open the dispatch queue, then again when we open each incident.

When incident data gets edited in one context (tab/window/etc.), it does not update in others. That can also be fixed by monitoring local storage events.

[wsanchez]

Some useful info on this in #92.

[wsanchez]

The need to synchronize incident data across contexts is reduced a bit by the fix for #92 we we still can have the dispatch queue and the open incident both open, and we do want those to stay in sync.

And we also want shared loading and caching between the dispatch queue and the incidents.

If we start with the shared cache, then the remaining thing is that when one page updates an incident, that the others notice and load from the cache. So let's start with the caching.

Looks like lscache doesn't have good support support for listening to events (there's a ticket open for it), so we may want to avoid using that for incidents, though I like the idea of an expiration, in case of failures to invalidate the cache.

A danger here is that we don't want to fill the allowable caching size per origin, so we need to figure out a way to measure our usage and make sure we stay under it. Apparently that's 5MB in pretty much every browser. lscache has a convenient API for flushing everything, which would be really handy if we could detect a full cache (eg. you opened every event's queue and therefore cached all incidents in all events). But again, seems like we can't use it.

[wsanchez]

Actually, it looks like the keys that lscache uses internally are simply the given keys with an lscache- prefix, so setting up change events on that should be as simple as direct usage of local storage, though without an API, we need to beware that this is an abstraction violation that can bite us later if we upgrade lscache versions.

[wsanchez]

Wait, we can't have caching without server push because if an operator on another host (or same operator on another browser) makes a change, we won't see it, even on reload, until the cache expires.

So we can only use local storage for cross-context sync and any reload of an incident page… or the dispatch queue… should always reload data from the server to make sure it's relatively up-to-date.

There's some monkey business we can do to display from cache then reload then update the view, but we have to be cautious about caching traps here.

[wsanchez]

ie… I got ahead of myself. @kimballa's single-user suggestion in #92 is a valid strategy that doesn't include the above monkey business. I'd still keep the expirations in lscache, probably set to a minute.

[wsanchez]

I should stop talking to myself and go to sleep, as I'm unclear that I'm being clear and/or coherent.

However, I'll note that I'm not especially worried about some of the concerns expressed in #92 about stomping on a user edit-in-progress because edits to the metadata fields (ie. not adding a report entry) are small and somewhat disposable, and because causing an update in another tab is unlikely to stomp on such an edit-in-progress given how the UI works, which is that when you exit a field, it's sent to the server as a field-specific edit (that is "update summary to X").

Any pending edits to report text, which a user could very rightfully be very annoyed by any stompage won't happen, because the report entries are append-only, and an incident refresh should not clear the new-entry-to-add text field.

[wsanchez]

Punting this because #46 is even better and I have that working. We may still want localStorage for caching/performance reasons, but #36 gets us updates, which is more trés sexy.

[srabraham]

I think we're in a pretty good place with this, with EventSource and with reloading of Incident data in each browsing context (browser tab) on updates from the server.

As an example of how this works now, let's say I have 5 tabs open:

• One tab on the dispatch queue (Incidents page)
• Three tabs on IMS Show logged in user in Web UI #11
• One tab on IMS Update web UI to handle new location schema #12

Exactly one of those tabs will be subscribed to the EventSource, and it will broadcast any update to all the other tabs, via a BroadcastChannel.

So, now, if someone on a different computer changes IMS #11, IMS will send an event over EventSource to our computer indicating an update to that incident. The dispatch queue tab and the three IMS #11 tabs will all separately do GET requests at IMS to fetch the latest details about IMS #11, so there will be four identical calls from that browser in response to the one EventSource event.

It would perhaps be better still to only make that call once, but caching introduces various things to worry about. One simple one is that incident data, which can contain sensitive personal information, would almost unavoidably persist in LocalStorage after the user is gone. That's not ideal on shared machines like we have on-playa.