Getting mutation data in different component after mutation returns data from backend

[MarvinCorro]

Let's say there exists a user dashboard component. In this dashboard, the user can create an event that collects a bunch of information to send to some backend to create this event and store it in a database. When the event is created, the backend returns the event data to the client, and the client changes views to show the event details. The issue I want to address is if the dashboard component unmounts and a new event component mounts, what is the correct way to get that data that just came back from the mutation?

There are a few ways currently to do this, but they all seem like workarounds rather than something that addresses this problem.

Fixed Cache Key: Using a fixed cache key to share the mutation data between components. This, however, feels wrong as I do not want to use the mutation hook to access data, especially if the new component just needs access to the data and not that specific mutation.

Query All the Data in the New Component: In this approach, we can query the backend from the new component for all the same data. This doesn't seem like a good solution either, as we will have a bunch of redundant API calls for data we already have.

Store Data into Slice: We can store the event data in an event slice and access it that way. This is what I think most people would do, but this seems to violate the principle of app state vs. caching API data. Even though my application state depends on this event data, it's not really global data, and it's only used for that one event component. It seems redundant that I have to have that same data in two places now, and one can become old and stale.

There is nothing inherently wrong with any of these methods; each one just feels like a workaround. Maybe there is a way to access mutation data directly by looking at the store, and I completely missed it, but while reading the docs, I could not find something to address this question. Any input would be helpful! Thank you.

[MarvinCorro]

Bump 😀

[markerikson]

So, generally it sounds like the use case is "cache some of the response from a mutation for later reads"?

Yeah, assuming you don't want to go with the fixedCacheKey approach, seems like doing something to save the result in state is reasonable. You can either listen for the mutation fulfilled action in a slice, or use the onQueryStarted lifecycle in the mutation endpoint and explicitly use something like upsertQueryEntries to pre-fill that as a cache entry that could be read via query hooks elsewhere.

(We may eventually try adding a new endpoint option that lets you map the response to other cache entries automatically, but for now you'd have to write the logic yourself inside of onQueryStarted.)