Cache object mutation about apollo-cache-persist

[jamesreggio]

@ShockiTV — I appreciate the guidance, but we've decided upon this API for the sake of developer convenience, and we're going to leave it as-is for the time being, so as to avoid a breaking change.

If you'd like to block until your cache has been restored, you can simply await persistCache({...}) or await persistor.restore(), both of which return a promise.

[jamesreggio]

Hi @ShockiTV — could you explain what you mean by 'triggering'? Is the patched write method causing actual problems in code, or is it just offensive to your ideological purity?

If the former, I'd be happy to investigate with further details. Otherwise, consider opening a PR.

[ShockiTV]

Hi, yes it is kinda ideological. I dont speak TS so I cant just simply PR this.
I would suggest that persistCache would return it's own instance of cache object pointing to old one, but with patched write method if needed. The patch would be on internal object, not on "global" cache itself.
Similar CachePersistor would return persistor which would have getCache() method to get it's own instance of working cache.

Current way of hard patching write method on trigger in onCacheWrite could happen on this internal instance which you can than pass to ApolloClient.

When there is full control of instance of cache passed to ApolloClient, we can maybe get some agreement how to signal ApolloClient to wait with initial query load till we finish restore().
Currently it feels like kinda race if restore data comes fast enough before ApolloClient try to fetch things from BE. And if they come late, they will replace perfectly fresh data from BE with stales.