Subscribe to a single item of a bulk query

[sbruinsje]

My UI consists of a virtual list of items on the left and a single selected item from that list on the right. The list of items on the left is loaded using a bulk query using one of the hooks, like so:

const { data } = useGetItemsQuery({ slice: [0, 20], searchText: "football" });

Now I would like the right side of the app to subscribe to a single item from the bulk query. RTK query supports selecting an item from another query result, but the problem is that since our list of items is virtual, when the user scrolls a different slice of data is loaded which may not include that particular item anymore. Is there a way to make a component subscribe to a specific item from a bulk query and force it to be kept available?

[markerikson]

RTKQ doesn't know anything about the contents of a given cache entry - it just knows "there are N subscriptions to this cache entry with this key". So, it doesn't know that a key of { slice: [0, 20], searchText: "football" } contains, say, item 17, and that you want to keep around item 17 - it just knows whether there's a subscription to that cache entry as a whole.

So, you'd have to have the other part of the UI use the same cache entry key in order to keep reading that specific value out of the cache entry.

[sbruinsje]

Ah ok I see.

Lets change the example a little bit:
In a list you can select items using a checkbox. The ID's of the selected items are stored in the redux state. The items aren't stored as entire objects because those would become stale if the the item would get edited. Since we only have ID's in the state, the different places in the app that do something with the selected items need to:

1. ... either load the item by their ID themselves.
2. ... or subscribe to the cache entry they originated from.

Option 1: has the problem that whenever you do some mutation that invalidates the "items" cache entries, a whole platoon of requests may be fired to reload each selected item by ID seperately.
Option 2: has the problem that now our components need to keep track of exactly which cache entry the selected item originated from just to make sure the item's data stays available.

RTKQ aims to relieve developers from keeping local copies of entities as managing that can become complex, but I feel like the complexity kind of switches to having to track cache entries. Maybe I am overlooking something, or maybe it depends on the complexity of the app on how well suited rtkq is for it. I'm curious what you think.

[markerikson]

Not sure I have a specific answer, tbh.

Big picture, there are definitely some use cases that RTKQ will work well for, and others where it won't. That's a combination of the API design (cache keys) and the implementation (non-normalized / "document"-style caching), as well as limitations of React hooks (not being able to render varying hooks).

I did respond to someone else in a recent thread that involved a seemingly similar use case (checkboxes that led to a query string along the lines of of &items=id1,id2,id3), and noted that RTKQ just isn't a great fit for that case because of the mismatch between the constantly changing params (and thus the cache key) and RTKQ's data model.