Yeah, right now the app is using simple page numbering for pagination, which means data refetching is very naive and just re-requests all queries/data. If we used cursor based pagination (I like the Relay Cursor Connection flavor, and plan to update Part 5 with it), refetching when reconnecting to the WS can just be querying for missed messages starting from cursors ~ much more efficient.
For offline message storing, I’d definitely suggest
redux-persist. Actually touch on it a bit in Part 7 of this tutorial, but intentionally didn’t persist the
apollo store because you have to write a bit of extra logic refetching data once you reconnect online, and the tutorial is long enough already :) It should also get easier with cursor based pagination as well.
Regarding mutation retries, there’s a good thread here on where
apollo-client is at on this. Right now,
optimisticResponse will rollback on any failed requests. So for now, you could write a custom redux store for failed messages that could insert and render those failed messages in the list of messages where they belong, and on successful retry/cancel, just remove from the redux store. I don’t think
optimisticResponse would mess this up, but this is definitely a workaround — there should be something more elegant we can build into
Let me know your thoughts!