-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updating cache with local resolvers doesn't update the UI #5781
Comments
Solves #5781 by keeping data written by cache.writeData from appearing incomplete just because it does not have __typename fields that were not explicitly present in the original query. Since InMemoryCache#transformDocument is responsible for adding these __typename fields automatically, it makes sense for the StoreReader belonging to the InMemoryCache to detect and ignore those fields later, rather than handling this somewhere else, like the QueryManager#transform method, where transformDocument is called. @hwillson Another way of looking at this issue is that this bit of code in the queryListenerForObserver callback is mishandling "incomplete" data, as we've observed before: const resultFromStore: ApolloQueryResult<T> = { data: stale ? lastResult && lastResult.data : data, ... The changes in this commit work around the problem by removing a category of __typename-related reasons why stale might be true here, but I think we still need to decide what staleness should mean for this logic.
) Solves #5781 by keeping data written by cache.writeData from appearing incomplete just because it does not have __typename fields that were not explicitly present in the original query. Since InMemoryCache#transformDocument is responsible for adding these __typename fields automatically, it makes sense for the StoreReader belonging to the InMemoryCache to detect and ignore those fields later, rather than handling this somewhere else, like the QueryManager#transform method, where transformDocument is called.
@jthistle Ok, a fix for this issue has been published in |
Thank you, I'll try it and let you know. |
Ok, my demo is working great now! Thank you. However, there is still a problem. If you have a look at this sandbox, you can see the map center has the |
I haven't dug into that sandbox yet, but I would recommend using |
OK, I see. I'll try that and get back to you. Thanks again. |
I'm having a really weird problem along the same lines... but I can't reproduce it in a sandbox 😱. Can you see anything wrong with this setup?: I have my client cache set up with this initial state: const initialState = {
mapControls: {
viewMap: true,
zoom: 16,
center: {
lat: 0,
lng: 0,
},
},
}; And in my resolvers, I resolve a const resolvers = {
Mutation: {
updateCenter: (_root, { lat, lng }, { cache }) => {
const query = gql`
query mapCenter {
mapControls @client {
center {
lat
lng
}
viewMap
}
}
`;
const { mapControls } = cache.readQuery({ query });
// Some writing to cache occurs here but is irrelevant
return true;
},
}
// ...
} The FWIW, I'm calling this mutation using mutation SetMapCenter($lat: Number!, $lng: Number!) {
updateCenter(lat: $lat, lng: $lng) @client
} I have no idea what's happening :( |
I believe I am running into the same (original) issue, but I am on edit: nevermind. I've migrated off boost to the newest beta (.24) and my issue remains, so perhaps it is something else. conceptually it appears very similar to the original post's codesandbox example |
@benjamn any plans to fix issues with Apollo Local state soon? I've been running into several issues with it. I like the idea of being able to do GraphQL on both client and server but it just seems the local state side of apollo has a lot of issues. |
@lifeiscontent See #5799? We are hoping to transition away from the AC 2.x local state implementation, though it's going to remain in the codebase for the initial AC3 launch. |
This has a label of "Fixed in prerelease". I'm on V3.0.0-beta.36 and I still see this issue. Mutation and query in the same component. When I mutate state, the query doesn't refresh even after calling
The output sequence is:
As I step through the code, I can see that immediately after writing the data, it's in the cache ('write1'). But the subsequent query ('res1') shows a cache that is empty. So, it seems like the cache reference is outdated or is reset. We get an error if we use react-native-debugger similar to the one we got before we implemented the react-native-debugger network inspect fix. The same error doesn't occur with standard Chrome debugger.
|
If instead of
Now the query gets an update, but the cache apparently remains empty or gets reset. |
Just a follow up on my comments here. I create a code repo and I couldn't reproduce the issue there. So obviously, something else is going on. For those who might find it useful: https://codesandbox.io/s/naughty-glitter-wzmof The actual cause for my issue was an undetected remount of the ApolloProvider which lead to the cache being cleaned. |
I've spent the past part of a day trying to understand why my cache was updating via the |
See a minimal reproduction here, since it isn't easy to explain: https://codesandbox.io/s/fervent-hawking-o2bt5
If you watch the console, you can see that when you click the button, the resolver is running and the new data is being written to the cache. However, the
useQuery
query in the UI (App.js) is not rerunning, and the data is stale as a result.Expected result
Versions
@apollo/client @ 3.0.0-beta.20
The text was updated successfully, but these errors were encountered: