What kind of Apollo Client Type Policy for infinite scrolling and paged search both?

I recently updated the apollo client package in my work to use version 3, and some things I can’t quite grasp just yet. Like defining type policy globally per query name. Here’s my issue, at work we have a search query, an offset based one, and it’s used in very different UI contexts. We have views that are table like with lots of paged data, and then we have infinite scroll type of feeds.

I have found that a single type policy for query search does not really quite support this. Here is our type policies:

typePolicies: {
  Query: {
    fields: {
      search: {
        keyArgs: (args, context) => {
          const keyArgs = ['ascendingSort', 'input', 'sortField', 'size'];
          if (context.field?.alias?.value === 'pagedSearch') {
            keyArgs.push('from');
          }
          return keyArgs;
        },
        merge: (existing, incoming, { args }) => {
          const start = args?.from || 0;
          if (!existing?.hits?.length) return incoming;

          const { hits, total, maxScore } = incoming;

          const mergedHits = existing?.hits ? existing?.hits?.slice(0) : [];
          hits.forEach((hit, i) => {
            mergedHits[start + i] = hit;
          });

          return {
            ...existing,
            hits: mergedHits,
            total,
            maxScore,
          };
        },
      },
    },
  },
};

The hacky part here is that we are using field alias:

pagedSearch: search(input: $input from: $from) for search query and pushing offset variable to the keyArgs of paged queries, so user gets fresh results when they change the table’s page.

if (context.field?.alias?.value === 'pagedSearch') { keyArgs.push('from'); } This does get the job done for now, but I want to know how would one implement a single type policy for these type of queries?

I have asked this question on stack overflow a while a go, but no answers yet https://stackoverflow.com/questions/68157953/what-kind-of-apollo-client-type-policy-for-infinite-scrolling-and-paged-results

[SkinyMonkey]

By the way : I feel like when an alias is setup on a query, apollo should use it instead of the original query name.

[benjamn]

I honestly think returning everything from the read function (ignoring offset and limit) is the most flexible option for both infinite scroll and paginated navigation, because then you can use application/UI-level logic to slice the big array into chunks for pagination (in a part of your code where you probably have enough context to make that choice), and you don’t have to keep updating the offset and limit of the original query each time you fetch new data, and both queries can consume the same underlying list of data (rather than maintaining separate lists in the cache).

This difference between paginated and non-paginated read functions is discussed here in the docs. I’m specifically recommending the non-paginated approach.

---

If you’re not sold on the one-big-list philosophy, and you want to keep using @connection, keep reading for some additional thoughts…

Since keyArgs is intended to replace @connection, I would hope you can just use keyArgs, but I admit @connection can be useful to inject arbitrary key information, and is conveniently already understood by most GraphQL tooling (unlike other directives or arguments you might make up).

While InMemoryCache does support @connection in the absence of keyArgs, prior to AC3.5, there was a pitfall where providing keyArgs would cause @connection to be ignored (see #8659). Thanks to #8678 (released in v3.5), it’s now possible to include information from any directives (or variables) in your keyArgs array:

new InMemoryCache({
  typePolicies: {
    Query: {
      fields: {
        search: {
          keyArgs: ["query", "@connection", ["key"]],
          merge(...) {...},
        },
      },
    },
  },
})

This configuration will produce field keys like search:{"query":"...","@connection":{"key":"searchInfinite"}}, so the @connection(key) information is handled sort of like an argument passed to the field. You should not need to pass a filter argument to @connection, since that’s what the other strings in keyArgs represent.