feature idea: Manual Cache updating outside of mutations about apollo-link-state

[jbaxleyiii]

➤ Kenneth Bambridge commented:

Do you have to update the store? The store is meant to be a cache of back end data. Perhaps you can map data from the store into the final version you will show in your UI?

[jbaxleyiii]

➤ falconmick commented:

To simplify, 1st query causes another query to have to be run. Right now that means the front end has to spend 2x as long purely on ping from server to client. When I run the 1st query, as soon as it gets to the resolver of the type I can figure out all the extra data I need and add it to what ever the query returns. The issue is that I cannot use update from within a query to manually fix the cache whereas if it were a mutation theoretically I could (theoretically as I’ve never used update before, just read doco)

Does that help?

Cheers

[jbaxleyiii]

➤ Kenneth Bambridge commented:

Hm what about storing that data separately in the redux store? If you have a unique id for each object in the store then you could store that data separately and combine it in your components.

[jbaxleyiii]

➤ falconmick commented:

I could, but then I cannot utilise one of apollo’s Key gains which is it’s basically magic automatic cache. I would then need to intercept queries before I send em and parse them looking for any in my cache...

And if I just resolve the data that was prefetched for the sub components to my components I could still get the benefits of the cache for that query, but if the data returned were to be a part of a direct query (not sub query like from a page) I would have to fetch it as it’s not in apollo cache. Not to mention the queries attached to my component would need to be somehow told to not fetch as I have already passed em to the component.

However it is definitely an option, if using mutations is either too messy OR not viable I’ll give it a go. Also once I upgrade to 2.0 I’ll have a go at adding update to queries and maybe make a PR