Local Caching

[nofurtherinformation]

This PR adds clientside caching for gerrydb views and zone assignments for better user experience and lighter server loads.

Description

• Adds a timestamp updated_at sent with update assignment patches to track versioning. This handles asynchronous changes but will not currently alert the FE to changes happening while they are active
• Uses indexeddb via (idb package) to cache gerrydb views, map state, and map state updated at timestamps
• The document table already has an updated_at property, so this does not change db schema
• The FE already gets the full document row, so it can check if its latest cached timestamp matches the database without pulling the full assignments
• The idb implementation to cache the state will store the assignments, shattered IDs and shatter mappings; the store state is very close to the in-memory representation to streamline reads and writes
• LocalStorage would work and may be easier, but with this approach would be limited to ~66 cached plans, which for power users could be hit

Reviewers

• Primary: @raphaellaude
• Secondary: @mariogiampieri

Checklist

• Update timestamps
• Cache map state in idb
• Cache map state updated timestamps in idb
• Cache gerrydb views in idb
• Reload map state from idb conditionally
• Reload gerrydb views from idb
• Test if better to fully stringify or just convert to plain JS objects
• Test perf implications
• User test / bug squash

Screenshots (if applicable):

[nofurtherinformation]

After some testing, storing vanilla js objects and converting to map/set structures is faster than fully stringifying

[raphaellaude]

This works so so well and feels way better for the user. One small change requested on the backend.

Other than that, I noticed that when the user reloads we load from the local cache OR the remote store. I'm wondering if there's a case for the AND approach: first load from the local store, then verify with the remote store. Since we're in the single user per map paradigm I figure this approach is fine, but wanted to discuss trade-offs. Thoughts?

[raphaellaude]

I: Why these two params? Since you're passing the session from the caller, if the caller errors later all operations in the session's transaction will be rolled back. So you can safely execute this w/o worry.

[nofurtherinformation]

Ah, that's a good call!

[nofurtherinformation]

This works so so well and feels way better for the user. One small change requested on the backend.

Thank you!

Other than that, I noticed that when the user reloads we load from the local cache OR the remote store. I'm wondering if there's a case for the AND approach: first load from the local store, then verify with the remote store. Since we're in the single user per map paradigm I figure this approach is fine, but wanted to discuss trade-offs. Thoughts?

That's a good question -- we take this approach for the map views caching (local but verify). I think my two questions here are:

• Is it worth saving the extra load / capacity on the backend?
• If the user paints before the backend assignments respond, how do we reconcile the state?

[raphaellaude]

If the user paints before the backend assignments respond, how do we reconcile the state?

Hmm yeah true that would be difficult. You've convinced me that we shouldn't pull.

Another approach might be to do a full document push to the server using the local cache then?

[nofurtherinformation]

If the user paints before the backend assignments respond, how do we reconcile the state?

Hmm yeah true that would be difficult. You've convinced me that we shouldn't pull.

Another approach might be to do a full document push to the server using the local cache then?

I believe this is the case currently but will double check tomorrow!

[raphaellaude]

lgtm – we can leave the push pull discussion for another time / an issue rather than PR

Saw a couple of sentry errors come through. Let's handle those before we merge.

[raphaellaude]

apparently the above errors were from a local build so re-approving!