-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use localStorage to cache incidents and synchronize data across contexts #96
Comments
Some useful info on this in #92. |
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 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. |
Actually, it looks like the keys that |
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. |
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 |
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. |
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.
The text was updated successfully, but these errors were encountered: