0

Is it possible to query the Apollo client cache to get a list of filtered data on the client?

After the client fetches data from the graphql server, the data can be seen as being on the local cache from Apollo dev tools.

How can I get a list of 'Item' types which match a set of 'tags' without making a trip to the server?

type Item {
 id: ID
 text: String
 tags: [String]
}

I would assume this is viable with Apollo-link-state custom resolvers, but so far haven't been able to figure out the strategy for it or find an example anywhere online.

I'm aware that Apollo cache's the data by the queries that have been executed and can access it with the ID and .readFragment, but if the data already exists in the client cache, it should be possible to get a list of data for a certain condition?

Update:

The exact requirement is as follows

  1. Get first 100 results for getItem from the Server
  2. User filters the results by some tags on the client
  3. Show the filtered items from 100 records already fetched
  4. FetchMore records to match the filter criteria from the server to fill up the rest of the page upto 100 items.
  5. Allow pagination based on filter criteria.

As more usage happens, we would have most of the items in cache providing a instant filtering experience for most of the data.

The exact question is can we use .readFragment or .readQuery to access the raw list of records and filter on the fly in the client (if so how/example)? Or is there another way to look at this?

Chands
  • 345
  • 5
  • 10

1 Answers1

1

This kind of functionality can be achieved using apollo-link-state.

example - 'internal' query can be forced to be cache-only by fetchPolicy

Also consider simple filtering in component state (or other options - it all depends on (sharing filtered result) requirements.

xadm
  • 8,219
  • 3
  • 14
  • 25
  • Thank you for this answer, I should have been more clear about the exact usage. I've updated the question above. Would be great if you can have a look at it! – Chands Sep 12 '18 at 00:06
  • Actually, trying it IRL, 'cache-first' fetch policy gives almost the same experience. Thank you! – Chands Sep 12 '18 at 01:12