re-fetch after mutation rtk query

[phoique]

Hello, I am new to the rtk query structure. In the example in its document, in my example, it sends a fetch request again after the mutation operation, shouldn't it instead update the data in the cach?

https://codesandbox.io/s/github/reduxjs/redux-toolkit/tree/master/examples/query/react/mutations?from-embed
For example, after editing the todo, it sends a request to the todos endpoint again.

Another question is, I have users and user search endpoint. They both look at 2 different queries, but the result they bring is the same, someone just returns the filtered result. In an example scenario, searchte is user_name: Jhon, and users all queries are in the form of jhon. Can I change the current value of the id of that last user from the cache? In providesTags, both queries have the same type and id, but it does not work.

[markerikson]

You can do optimistic updates if you want to:

https://redux-toolkit.js.org/rtk-query/usage/manual-cache-updates#optimistic-updates

But RTK is specifically designed around the idea that "the server is the source of truth", and so it will re-fetch the data after update when the endpoint is invalidated.

Afraid I don't understand the second question.

[phoique]

If I do an Optimistic update, it will request again. It doesn't make any sense, does it?

My other question is, does rtk query automatically update a mutated value in any of the 2 different queries (userList, userSearch)? 2 ProvideTags values and ids are the same,
"{ type: "Users", id: id }" all I want is to cache the lasted value. For example, the user with id 3 appears as A in the userList. It looks like B with a search request. When a return is made, I want it to be in its final state, that is, in b shape. Can rtk query do this automatically or will I do it with an optimistic update?

I hope I was able to explain, thank you.

[markerikson]

It does make sense. RKTQ has no way of knowing that you just made an optimistic update and that the cache is 100% up to date. Besides, you are the one who told it that "mutation X invalidates query Y", so it's following that behavior.

And no, each query cache entry is completely separate. If you have entries for /todos/3 and /todos that also includes todo 3, those are completely different copies of that todo object in the cache.

[phoique]

Well, thank you very much for your answers, I have one last question. When performing an optimistic update, for example, when the post is updated in the updatePost operation, getPosta requests are thrown and updated by taking the current value from there. In my scenario, after sending an updatePosta request, it returns me the updated post data as a result, so I don't need to send a getPosta request. In the examples I have examined, the updateQueryData is always making a request somewhere, what should be done in this case?

[phryneas]

The request is made because you specified providesTags and a matching invalidatesTags. If you don't want automatic refetching, don't use the automatic refetching feature.