Refreshing related lists

[yngwi]

Hi,
we were already discussing this topic on Spectrum but I'm not sure what the last state of the discussion was, I didn't really know the best way to do things after it so please excuse my asking again here. I hope this is OK.

Anyways, I wonder what the best way to refresh related entities in lists is after a mutation is. This is something that happens all the time for my app as all the entities are interrelated. People have birth places, companies have headquarter places, publishers have publishing places books have articles printed in them and so on and I want to display this connection of things and their related things at both ends of the various relationships. A person has the birth place listed and a place will have a list of all people that are born at it. This can be queried because in my GraphQL schema it is possible to ask the following (and similar queries):

Person:

{
  person(id: 1) {
    id
    birthPlace {
      id
    }
  }
}

Place:

{
  place(id: 4) {
    id
    peopleByBirthPlaceId {
      nodes {
        id
      }
    }
  }
}

As you can see the data of people born at a place is a list so entities are not automatically added to the list of a place if it is added as a birth place for a new person and it is not automatically removed if the birth place is changed to something else. In Apollo I just created a function that updated the cache after each mutation by having a look at the cache before the mutation and removing the things from the lists that they are not part of after the mutation and adding them to the lists that they will be part of after the mutation. I have no idea if this was the proper way to go (probably not) but it worked.

So, what would be the best way to keep this kinds of relationships up-to-date? Also (a related question) is it possible to get the state of a mutated entity before the mutation in the cache update handler?

Thank you for your help, I like your client very much so far!

Daniel

[yngwi]

Hi again,
to specify the last part of my "related" question: during an after-mutation-update, is it possible to get the state of the mutated field before the mutation to do some updated on the cache (like the relationships mentioned above)? It seems possible to use the cache.inspectFields("Query") method go through the whole state and to find things that need updating but all this data is often already known because it follows directly from the state changes of the field during mutation, before and after the change.

Thanks again,
Daniel

[kitten]

I'm not quite sure I understand the question; are you talking about optimistic updates or updates in general as covered on the Graphcache docs page?

[yngwi]

Hi,
thank you very much for your response!

The most basic way that mutations can affect lists is handled in the custom updates documentation. It shows how to handle simple additions/removals by knowing what queries are affected and by just appending the object at the end (or removing it) without logic that depends on other parts of the cache / specific changes in the objects.

My question is about mutations that might make updates in lists necessary depending on additional logic. Please consider this use case:

I have an app that enables the additions of persons and the place where they currently live to a database. An individual person can be viewed and the name and living place displayed and an individual place can be viewed and contains its name and the list of persons currently living at it. The data of a person can be changed by using a form that submits the new state of the person and enables the changing of the name or the living place.

Now, consider that a user has already viewed some places so they are already cached and is now changing the living place for a person by submitting the form and triggering a mutation. The response for the mutation contains the updated data for the person with both their name and their current (possibly new) living place. If only the name changes the cache is of course updated automatically because the normalized object is changed directly, but if the living place is changed, the cache for the old place needs to be updated in the sense that the person is removed from the list of the persons living there and the new place needs to have the person added to the residents list. This can either happen by mutating the cache or by invalidating the data of both places so they are just re-fetched with the correct data.

What I am wondering now is if this is indeed the only way to make such updates in the cache and what the best way would be to actually do it.

One problem for instance (in this case) is that the updating method doesn't know the state of the directly affected objects before the mutation (the old living place for the person that was cached just before the mutation happened) so the method always needs to go over all objects of the affected types (in this case places) check if they are affected and modify them so they match the expected state (add to list / remove from list).

I hope this makes a bit more sense than the initial description of my problem. Anyway, I'm very grateful for any input on this.

Regards,
Daniel

[kitten]

In that case it depends; you can invalidate the Person entity, but it's also possible (if there's a reverse relation like Person.place) that you can get the place using that property then add on the Person like that to the Place's list.

So generally what we can assume is: parents leading to a mutated or added entity will be known by relations.
That means that when the lists are also known you can add them to the appropriate ones.

But yes, that's not always possible, which is why we have:

• The populateExchange which automatically tracks selection sets and hence is supposed to know what to refetch (RFC: Increase feature-set of the populateExchange for progressive Graphcache adoption #964)
• cache.invalidate and cache.inspectFields for changes

[yngwi]

Hi,
thanks again for your response. What I started to do now and what works well so far is moving through all related entities (places), testing each one if it should be modified using the data of this entity and the data of the modified entity from the mutation (I think that's what you suggest) and update if appropriate. The populateExchange plan looks interesting, I'll keep that in mind!
Daniel