refetchQueries not working when using string array after mutation #5419
Comments
|
I had a similar problem but was resolved by providing the exact object used to fetch the query which may include any variables, query options and etc. |
|
The whole purpose of using a string is that you should NOT have to provide the exact object as Apollo should automatically refetch the query with the current query variables. |
|
Yeah I totally agree with you there man it sure is a bug or documentation is wrong. Didn't mean to sound like it ain't a bug. It's very inconvenient having to provide the exact same object especially multiple mutations in multiple places refetches the query. |
|
I have a similar issue. The weird thing is that when I call a mutation where it deletes a row, and then I call the refetchQueries with a string, it actually works. But after I insert a new row, nothing happens when I do the refetch. It makes no sense because the delete is still a mutation, so I'm not sure what the difference could be. Both mutations return the same values. I'm looking at the network requests, and I see that after the insert there is no request, but after the delete, there is a new request that actually do re fetch The only way I could make this to work is to change the fetch policy to delete mutation refetch insert mutation delete mutation hook insert mutation hook |
|
I have witnessed exactly the same behaviour! It works fine when I refetch after I delete an item but not when I create one. |
|
Hi Friends, I have the same problem: refetchQueries works with update mutations, but nothing happens on insert mutations. Is there any known workaround? |
|
Impacting us here also... 😫 |
|
Also running into this issue |
|
I came accros this issue. If I cancel the redirect, which comes right after the mutation, there is no problem. After the query is refetched, cache gets updated. I think, when the page that observes the query gets unmounted, even if the network request gets completed, cache can not be updated. A cool way could be invalidating a query even if it wasn't observed by any active component. This is just a simple idea of course. There may be positive/negative points about this. Edit: After some thinking, I feel like using Most of the times I just don't feel it's ok to change the default |
In case anyone is still interested, this behavior happens because when you delete something, the component holding the original query didn't get unmounted (normally because you just show a popup), while when creating a new item you redirect to another screen (i.e. create item page) unmounting the page holding the original query. Apollo maintains a list of observable queries at any given time, which is based on which components are currently mounted that defined a query (i.e. through I don't know if @hwillson would like to give us more context as to whether there is a way around this (except from not using the React or by making sure that we unmount as little as possible on crucial refetches). In short:
|
|
So it's not possible to perform a refetch with the original query and variables? Doesn't sound to me a good choice :/ |
It's only possible if you don't navigate away (i.e. unmount the component that performed the original query). Your other option (which is not actually a solution) is to use a different |
|
I see; thanks! |
I have three components render on the same page which use the same query(and same operation name) but difference variables. |
|
cause it literally does just that. It refetches the query with the latest variables. From apollo's side it's only 1 query with 3 different invocations, so i tries to refetch the "latest" invocation. |
|
Still an issue in 3.1.5 on May 22nd 2020. |
|
What happened with this issue, please!! |
|
I think this needs to have option to refetch non observable queries. those flags can solve a lot of issues |
|
Apollo client 3.2.5 and issue is not fixed. Any updates? |
|
May be related to #3540 |
|
I have a very similar problem to the one you are experiencing here, I'm on version 3.3.11. |
|
@espinhogr got the same issue. In my case refetch was performed on a component that was already unmounted, and that - for some reason worked well on dev, but didn't on prod. Check your warnings (red ones lol), maybe that's the case for you as well. |
on the other side, |
|
Same here, working on dev but not on prod.... please help |
|
This is still an issue on 3.4.7 Reproduction: Navigate to 'Mutation' and click 'Mutate'. You'll see a console warning:
However as per the docs
it should work, as the query |
|
@jerelmiller Ah that makes more sense, thanks! I've tried that in the past and it does work for refetching, but my main problem with it is that it causes my query data to disappear from the screen until the refetch completes. Not the best user experience, so I'm still sticking to |
|
@dylanwulf there are definitely tradeoffs to each approach. If you know your query is "active" (like it sounds you have), then |
|
What I ended up doing is just placing all |
@alessbell you were not able to reproduce the issue because your app is rendered under React When unmounting a component, only one of each duplicated queries is removed from said array, refetch is thus successful because it matches the query name with the leaked query in the array. I've removed This difference of behaviour between dev and prod build is also very confusing (took me an afternoon of debugging to understand what was going on) so we could at least work on removing the leak under strict mode ? Or maybe what's in the works for 3.8 will fix that ? |
|
Hi for everyone, today I got stuck with the same issue. I have component A that has a list and a form for creating items for this list. There is also component B that only has a list from component A. In dev mode, everything works correctly, but in prod mode, the list in component B does not update automatically when creating a new item, only after page reload. |
|
Hi @jerelmiller! I've hit this You've said:
And yet, I seem to see the same behavior when I'm using the document (or at least I think I am). This is my code: export const GET_COLLECTIONS = gql(`
query GetCollections($input: GetCollectionsInput!){
getCollections(input: $input) {
id
name
}
}
`);
const [captureSnapshotsMutation] = useMutation(CAPTURE_SNAPSHOTS, {
refetchQueries: [GET_COLLECTIONS],
// The GET_COLLECTIONS query is not always active when this mutation runs,
// so we need to also manually evict its results from the cache. We really
// want this query to be re-executed the next time the snapshots page is
// rendered.
update(cache) {
cache.evict({id: "ROOT_QUERY", fieldName: "getCollections"});
},
});This results in Is all this surprising / indicative of a bug? |
|
Hi @andreimatei, That said, it's unrelated to the problem you are having here - there are in fact three different things you can pass into the
Nr. 1. and 2. should behave pretty much the same - I believe you wanted to use 3. instead here, so your code would need to change like this: const [captureSnapshotsMutation] = useMutation(CAPTURE_SNAPSHOTS, {
- refetchQueries: [GET_COLLECTIONS],
+ refetchQueries: [{ query: GET_COLLECTIONS }],Keep in mind that this "legacy" style will always call a query with the variables you put in here, independently if the query is currently in cache or not. So it's less of a "refetch this" and more of a "fetch this". |
|
Got it, thank you for the explanation! |
|
@jpvajda No news right? :) |
…f using refetchQuery (#5684) Closes #5057. RefetchQuery is unreliable - [it won't be executed if the component is unmounted](apollographql/apollo-client#5419), which is the case here because of the redirection that occurs after the mutation. We want to avoid using refetchQuery as much as possible, and write directly in the cache instead.
…f using refetchQuery (#5684) Closes #5057. RefetchQuery is unreliable - [it won't be executed if the component is unmounted](apollographql/apollo-client#5419), which is the case here because of the redirection that occurs after the mutation. We want to avoid using refetchQuery as much as possible, and write directly in the cache instead.
|
Any updates? That's a critical bug |
|
Hey @emil14 👋 I'm not actually sure if there is a bug here. From what we've established so far, this seems to be an issue more about ergonomics of the API than an actual underlying bug. Please take a look at the comments from me and @phryneas above. Are you encountering something different something different than whats already been mentioned? |
|
This worked for me after creating a new one: |
|
To my and I think many others understanding, the whole idea of refetchQueries is that I can invalidate/refetch any query from any mutation (although they don't know their respective existing) just with a smooth query name Document reference. Now being forced to invalidate/refetch queries either by 1. specifically pointing towards them with their exact configuration, or by 2. manually jumping into the cache to modify stuff seems to be a huge design flaw - I mean, how would the query know which pagination/filtering variables are currently used on eventually +10 other queries being inactive but turning active once a create/delete operation has been performed?). Now being forced to (due to 1. my mutation now knowing the inactive queries and to 2. minimize boilerplate cache-modification code) set all list queries in the application to "network-only" to have a smooth UI when delete or create operations occur does kinda remove the whole idea of a cache. Is there no way to allow a flag on the refetchQueries array objects to say, "refetch this query if it is active immediately, if it is not active, invalidate the query in cache (i.e., somehow mark/invalidate its prop in the ROOT_QUERY) and refetch next time needed? It feels like there have been plenty of different threads now reporting this unexpected and broadly unwanted behavior. Here: #7878 Or here: #11357 Or here: #5422 Since again a lot of time has passed since this was discussed last time, would you mind to look at this once again and do you know if any upcoming changes address this phryneas jerelmiller? |
|
Since this is exactly how it's supposed to work, refetchQueries is useless in my opinion |
|
@luap2703 I agree that this function is generally confusing, but it's also very widely used - a change to it would be breaking (even so in a subtle way that we'd want to avoid even in a major). We hear your frustration, and there's a good chance that we'll come up with a replacement with a different name in the future, but it's probably not going to be very soon, I'm sorry. |
|
Thank you @phryneas for replying! Since there's no major change incoming, what would you recommend as "best practice" to overcome the current limitation? Manually adjusting the cash? |
|
Tons of nuance there, unfortunately - in the end, what works best for you. |
|
I fixed it removing refetchQueries. Problem is that this query wasn't called yet I guess |
|
Same issue for me. 👉 This only happens in prod build. In dev build, the ListGet is refetched. Tested with apollo-client versions 3.9.11 to 3.11.8 |
…f using refetchQuery (twentyhq#5684) Closes twentyhq#5057. RefetchQuery is unreliable - [it won't be executed if the component is unmounted](apollographql/apollo-client#5419), which is the case here because of the redirection that occurs after the mutation. We want to avoid using refetchQuery as much as possible, and write directly in the cache instead.
Possible solution with expected outcomeIf anyone stumbles upon this, I had a specific use case where we would write queries like so: const getXQuery = (param1: string) => gql`
query get_x_query {
get_x_query(args: {param: "${param1}"}) {
field1
}
}`I wanted to invalidate the cache only if client.cache.modify({
fields: {
'get_x_query': (existing, { storeFieldName }) => {
if (storeFieldName.includes('the-id-I-want-to-invalidate-for')) {
return undefined;
}
return existing;
},
},
});
client.cache.gc();Then I wrote this helper function: /**
* Invalidate queries in the cache based on the query name and the string that the query contains.
* @param queries - An array of objects containing the query name and the string to invalidate the query if it contains.
* @param queries[].query - Which query to invalidate.
* @param queries[].invalidateIfContains - Invalidate the query if it contains this string. Otherwise, invalidate the entire query.
*/
export const invalidateQueries = (
queries: { query: string; invalidateIfContains: string }[],
) => {
queries.forEach(({ query, invalidateIfContains }) => {
graphqlClient.cache.modify({
fields: {
[query]: (existing, { storeFieldName }) => {
if (invalidateIfContains) {
if (storeFieldName.includes(invalidateIfContains)) {
return undefined;
}
return existing;
}
return undefined;
},
},
});
graphqlClient.cache.gc();
});
};Which you can then use like so: invalidateQueries([
{
query: 'get_x_query',
invalidateIfContains: `the-id-I-want-to-invalidate-for`,
},
]);Hope this helps someone out, I can see it also working even if you're not using functions for defining the query strings like in my project. |
Thanks! This, perhaps, is the most suitable solution for many who posted here. const SELECT_STUFF = gql`
query GetMeStuff($name: String!) {
stuffz(filters: {name: $name}) {
id
essence
}
}
`;So pass the |
|
Hey 👋 I know this is a long-running issue and that multiple issues have been brought here over the years, but I'm convinced that some of the issues described here could be related to an issue (#12164) that just got fixed (#12236) and released as A quick summary of the issue is that when passing I invite you to read the issue and the pull request if you would like to learn more about this issue. Otherwise, make sure to update to |
and others
Intended outcome:
After a create mutation, I want to refetch the list query to have the newly added item be displayed in the list, making use of the variables which the list query is run with previously.
As per the documentation, this should be doable:
Actual outcome:
When using the operation name as string in the refetchQueries array, no query is refetched, nothing is updated and no network activity is visible.
Versions
The text was updated successfully, but these errors were encountered: