Replies: 1 comment
-
I have a similar access pattern. Here is the approach I'm using:
When we want to filter/reorder the list, we do so via backend apis that return a list of ids. This is important, because it means they will not cause another bulk fetch of a sub-set of the items. The cache remains the same, but some components are shown/hidden as per the list. This is how we also handle deletions: the id list doesn't contain a deleted id so we don't render the component, even though it's still part of the cached payload. If ever in doubt about cache inconsistencies, reload the whole list. Hope this helps |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I want to allow users to edit each item in displayed in a list. Each
<Item>
component has its own data fetching / mutation hitting the item endpoint/api/item/[itemId]
On load, does this mean that I'd be kicking off a bunch of api calls to
/api/item/[itemId]
for each item, in addition to the data I'm already getting from/api/items
(to get the list of items in the first place).Is there a more efficient way to do this? How can I leverage an API endpoint where I get all the items? For example, how can I share data from
/api/items
across the entire list of items?Beta Was this translation helpful? Give feedback.
All reactions