Part of my frustration with apollo is I've spent h...
# prisma-whats-new
d
Part of my frustration with apollo is I've spent half the day just trying to update my store onto another page. And now it seems like I have to do this. http://dev.apollodata.com/react/initialization.html#fragment-matcher
d
I'm not sure what the connection beetween fragment matchers (used to enable fragments on interfaces) and using your store on another page. Could you explain what you are trying to do? Maybe there is a simpler solution.
d
I have a list of projects. To create a new project, it goes to a separate route for the create project form. I'm using writeQuery to update the store. But the store is not getting updated with the new record. There is no error, but I verified that the data object I place into writeQuery has the new record.
And if I go to the new project page directly, (where the store has less data), it does in fact update properly.
I ran into a github issue that sounded similar to my case, where they introduced the fragment matcher. But yes it turned out that wasn't my problem.
I think for my case people generally just force refresh. But that seems to go against the whole point of apollo.
d
@dardub in my opinion simplest way is touse
refetchQueries
(http://dev.apollodata.com/react/cache-updates.html#refetchQueries) for a mutation, it will fetch specified queries from server again ... it's not the performance winner, but still better then reload whole page I would say 🙂
updating store cache can be tricky, I personally haven't slain that beast yet
d
@Daniel K. I meant refetch, not refresh. And that's my point, I thought the reason for using apollo was was for it's performance optimizations and caching. Otherwise I could probably just fetch my own queries and use redux.
d
I see, well I guess that best course of action would be to use debugger and investigate if you are writing to cache correctly