You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm building a web app for mobile which could require long-form data entry, such as writing out a talk proposal.
User Story
As a speaker submitting a talk proposal,
When my computer goes offline,
I expect to be able to submit my proposal in a "pending" state,
And I expect all "pending" submissions to be automatically saved when I'm back online.
Possible solution
Query caching is already built in to Apollo Client by default, but there's no equivalent for offline mutations.
It's possible to do this in user-land with the update() function on Apollo mutations (which will update Apollo's cache, and optimistically return that result immediately to your UI), but as soon as the network request fails, it will roll back the optimistic update.
apollo-link-retry exists to support retrying the network request with configurable limits & delays, allowing the optimistic update value be "the truth" until the client is back online.
But it does not persist the operation (semi-)permanently (say; you're tethering to your phone and your phone's battery runs out) - it will eventually stop retrying and so fail the network request and Apollo will roll back its cache.
It is a similar situation for closing the browser window - any optimistic mutations will be lost (as the apollo cache is all in memory). There exists apollo-cache-persist to help with this scenario.
(How to tie all these 👆 together is outlined here).
But we shouldn't have to do all that work manually.
Keystone knows a lot of structural and relational information about the way data is stored / queried. Ideally, we could leverage that information to auto-generate a library which wraps a React tree such that it transparently enables offline support.
The text was updated successfully, but these errors were encountered:
It looks like there hasn't been any activity here in over 6 months. Sorry about that! We've flagged this issue for special attention. It wil be manually reviewed by maintainers, not automatically closed. If you have any additional information please leave us a comment. It really helps! Thank you for you contribution. :)
Scenario
I'm building a web app for mobile which could require long-form data entry, such as writing out a talk proposal.
User Story
As a speaker submitting a talk proposal,
When my computer goes offline,
I expect to be able to submit my proposal in a "pending" state,
And I expect all "pending" submissions to be automatically saved when I'm back online.
Possible solution
Query caching is already built in to Apollo Client by default, but there's no equivalent for offline mutations.
It's possible to do this in user-land with the
update()
function on Apollo mutations (which will update Apollo's cache, and optimistically return that result immediately to your UI), but as soon as the network request fails, it will roll back the optimistic update.apollo-link-retry
exists to support retrying the network request with configurable limits & delays, allowing the optimistic update value be "the truth" until the client is back online.But it does not persist the operation (semi-)permanently (say; you're tethering to your phone and your phone's battery runs out) - it will eventually stop retrying and so fail the network request and Apollo will roll back its cache.
It is a similar situation for closing the browser window - any optimistic mutations will be lost (as the apollo cache is all in memory). There exists
apollo-cache-persist
to help with this scenario.(How to tie all these 👆 together is outlined here).
But we shouldn't have to do all that work manually.
Keystone knows a lot of structural and relational information about the way data is stored / queried. Ideally, we could leverage that information to auto-generate a library which wraps a React tree such that it transparently enables offline support.
The text was updated successfully, but these errors were encountered: