How to correctly do an update of the graphcache's paginated list after the create mutation?

[velidan]

Hi everyone. Sorry if the topic is common however I was looking in the previous posts and didn't find nothing relative\helpful.
I really need some help with the graphcache. In this case it's about the pagination list updation after the create mutation because I was able to do it similarly like in the case of Apollo update flow however I think it isn't a correct solution and must be something else I missed.

Sorry for the long codebase but it's important to understand the context. Basically I have the standard pagination list for the messages.
Here is the query to get it and the graphcache relay pagination config:

export const GET_CHANNEL_MESSAGES = gql`
  query GetChannelMessages(
    $communityId: String!
    $channelId: String!
    $threadId: String
    $before: String
    $first: Int
    $after: String
    $sort: String
    $search: String
  ) {
    channelMessages(
      communityId: $communityId
      channelId: $channelId
      threadId: $threadId
      before: $before
      first: $first
      after: $after
      search: $search
      sort: $sort
    ) {
      pageInfo {
        startCursor
        endCursor
        hasNextPage
        hasPreviousPage
        count
      }
      lastReadAt
      newMessagesCount
      totalCount
      edges {
        cursor
        node {
          id
          text
        }
      }
    }
  }
`;
...
cacheExchange({
      schema: introspectionSchema,
      resolvers: {
        Query: {
          channelMessages: relayPagination({
            mergeMode: 'inwards',
          }),
        },
      },
...

I'm executing the readQuery api and receiving the data, pretty strainforward.
Now I have a creation mutation

export const CREATE_CHANNEL_MESSAGE = gql`
  mutation CreateChannelMessage(
    $communityId: String!
    $channelId: String!
    $data: MessageCreateInput!
  ) {
    createChannelMessage(
      communityId: $communityId
      channelId: $channelId
      data: $data
    ) {
      id
      text
    }
  }
`;

It creates a message and my headache begins. I need to update the channelMessages query list
Here is how I managed to do it:

 updates: {
        Mutation: {
		createChannelMessage: (result, _args, cache, info) => {
				// getting a new message result
				const newMessage = result.createChannelMessage;

                                // receiving the arguments for the channelMessages field. limit/channelId/communityId
				const messagesData = cache
				  .inspectFields({ __typename: 'Query' })
				  .filter((field) => field.fieldName === 'channelMessages');

				 // Only 1 field for now. Is there a reason to iterate it?
				for (const messagesQueryData of messagesData) {
				  cache.updateQuery(
					{
					  query: GET_CHANNEL_MESSAGES,
					  variables: messagesQueryData.arguments,
					},
					(data) => {
				        // creating a new edge
					  const newMessageEdge = {
						node: newMessage,
						__typename: 'MessagePayloadEdge',
					  };
					  data?.channelMessages.edges.unshift(newMessageEdge);

					  return data;
					}
				  );
				}
                      },
	}
}

It updates the cache and the new items renders in the list without the page reloading however after the result inspection I found that it doesn't updates the pageInfo data of the channelMessages query result. I mean nor the cursors nor the items count.

I think it's wrong at all but I don't know what to do with that.
The main questions are:

1. Is it the correct way how to update the pagination list? Maybe this flow could be improved?
2. What to do with the pageInfo data? should I update it manually? Because I believe without the correct pageInfo things are fragile
3. Should I immediatelly re-execute the server query after the updation to get the real data from the server? I mean: maybe set cache policy like: cache-and-network etc.?
4. Should I do such manipulations for every query list I need to update by new item for an every creation mutation?

I appreciate for any help guys. This is the one of the few crutial things that block me from understanding how to correctly work with URQL
I even ready to pay money for help if someone ready to have a call and describe things deeply for me. Just, please, let me know and I'll be really glad to do it!

[kitten]

There is a very similar question that's been asked just a few days ago that I just responded to: #3207

Basically, make sure that you only update one page, preferably the last one if you're appending and the first one if you're prepending.

If you need to update the PageInfo fields a little, then you may have to do this on the first and last page.

It's not a bad idea to ensure that pages refetch, but keep in mind that you may not have to do this until the user starts interacting with the list again, unless you have a need to earlier.

Depending on how your pagination works, and if you don't use React Native, you may even be able to simplify and ditch relayPagination if you're willing to move your pagination logic to your UI: https://formidable.com/open-source/urql/docs/basics/ui-patterns/#infinite-scrolling

This may give you more flexibility when iterating over pages as on each load you can load the pages one by one.

Additionally, if you just want to "give up", you can use cache.invalidate in an updater to delete the pages from your cache.

[kitten]

Just to address the questions you had separately as well,

Is it the correct way how to update the pagination list? Maybe this flow could be improved?

Yes. You could even avoid using a complete query by providing a fragment and using cache.readFragment and cache.writeFragment.
That's preference based. You can't use cache.link in this case (which is often the shortest way to update relations) because you likely have to write the edge to the cache as well however.

But the simplest update is to only update the list field, the edge, and only select keyable fields on your fragment.

What to do with the pageInfo data? should I update it manually? Because I believe without the correct pageInfo things are fragile

You can if you need to. If you're using after / before then you'll have to make sure that, if the added item is relevant, you update the first or last page's pageInfo fields. However, you may not need to. If you append an item at the end of the list for instance, and you then query first: 10, after: $prevLast, so to speak, you'll get the 9 next items and the new item may get deduplicated away by relayPagination, so no changes may be needed.

Should I immediatelly re-execute the server query after the updation to get the real data from the server? I mean: maybe set cache policy like: cache-and-network etc.?

Again, you could but it may defeat the point of caching and you may then instead want to invalidate all listing fields, which is the last resort. That can be done with cache.invalidate, which can delete entities and fields from the cache.

cache-and-network may not always work because with relayPagination it'll only re-query the current page that you're providing variables for.

Should I do such manipulations for every query list I need to update by new item for an every creation mutation?

It depends. If you want to avoid a query then yes, if you don't need to, then no. It becomes essential if you want to perform an optimistic update. Otherwise, if it's not essential to update the UI as fast as possible, you can often get away with invalidating instead.

[velidan]

Thank you so much Phil for your help. I really really appreciate it because I haven't known about such details.
But if you don't mind I'd like to clarify some nuances I still can't understand

Could you, please, help me with these moments:
1)

You could even avoid using a complete query by providing a fragment and using cache.readFragment and cache.writeFragment.
That's preference based. You can't use cache.link in this case (which is often the shortest way to update relations) because you likely have to write the edge to the cache as well however.

But the simplest update is to only update the list field, the edge, and only select keyable fields on your fragment.

How to use the readFragment for the paginated Edges? I was thinking that the fragment it's a way to get some fileds from an entity in the Cache but in this case, looks like you mentied, the whole pagination edges?

I was trying to use this fragment but it doesn't reuturn a list of paginated messages

              // Result is undefined somehow    
              const result = cache.readFragment(
                gql`
                  fragment _ on MessagePayloadEdge {
                    node
                    pageInfo
                  }
                `,
                { ...messagesQueryData.arguments }
              );

---

2)
you could but it may defeat the point of caching and you may then instead want to _invalidate_ all listing fields, which is the last resort. That can be done with cache.invalidate, which can delete entities and fields from the cache.

I don't understand what did you mean by invalidate all listing fields. So far I know the cache.invalidate accepts an argument and typename of the entity that should be removed from the cache and the urql will automatically fetch relevant data from the server after that

          deleteChannelMessage: (result, args, cache, info) => {
            // Test. just invalidate to make an request and sync with the server automatically
            cache.invalidate({
              __typename: 'MessagePayload',
              id: args.id,
            });
          },

In this case I'm removing the message but I'm wondering how it could be implemented for the whole paginated messages list?

---

3)
If you want to avoid a query then yes, if you don't need to, then no. It becomes essential if you want to perform an optimistic update.
I need an optimistic update and it will be a next step. So if I understand correctly, when the optimistic update is necessary so it's important to manually update the cache in the updated in every mutation that requires the optimistic update?
The cache invalidation isn't acceptable because it's simply evicts the record from the cache and URQL just does re-fetch and the user will see the updated UI only after the server respond. Correct?

Thank you again

Kind regards.
Sviat

@kitten

[velidan]

Okay, since there is no asnwer for the clarification question, unfortunatelly, so I'll just share what I've done because it could be useful for others.

I ended up by just by manual changing of the count in the page info but without the manual changing of the start/end cursors. Seem everything works normally.
urql.config

...
createChannelMessage: (result, _args, cache) => {
            const newMessage = result.createChannelMessage;
            const messagesData = cache
              .inspectFields({ __typename: 'Query' })
              .filter((field) => field.fieldName === 'channelMessages');

              cache.updateQuery(
                {
                  query: GET_CHANNEL_MESSAGES,
                  variables: messagesQueryData.arguments as any,
                },
                data => {
                  const newMessageEdge = {
                    node: newMessage,
                    __typename: 'MessagePayloadEdge',
                  };
                  data?.channelMessages.edges.unshift(newMessageEdge);
                  // Here I'm updating the page info count
                  data.channelMessages.pageInfo.count++;
                  return data;
                }
              );
            }
          },
...

Thank you so much for your help @kitten