Hey Simon Tucker,
Ilija
1

Hey Ilija,

Great stuff!

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 apollo-client.

Let me know your thoughts!

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.