What kind of Type Policy for infinite scrolling and paged results both?

Help
,
1

Hi, 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 type policy for these type of queries?

2

Hi, did you manage to find a proper solution or guidance for this?

I am running into the same issue where I have a single query used in a datatable and load more list context and a single type policy causes issues on both depending on how i change it.

I will try to use your fix.

UPDATE

Thank you for your post, I passed a context variable in my query which isn’t defined in my named query but is still passed as a variable in the context object, so I used that to return the arguments based on context for the keyArgs based on your post.