-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Never merge fields in cache unless objects have same identity. (#5603)
These changes realize the consequences of the following extremely important principles: 1. In order to accumulate GraphQL data over time, the InMemoryCache must be able to merge the fields of different response objects together, as those objects are written to the cache. 2. However, merging the fields of two objects is allowable only when those objects have the same identity. If we cannot determine the identities of both objects (using __typename and id, or keyFields), or their identities are different, we should never merge their fields together, because doing so risks combining unrelated fields into the same logical entity object, resulting in an object that could never have been returned by the GraphQL server. 3. Even if two objects have the same identity, which allows us to merge their top-level fields, we should not assume we can recursively merge the values of fields that have the same name, unless those values are also identifiable objects with matching identities. Otherwise, we must replace the existing value with the incoming value, without attempting to combine them. Exception A: if the existing value and the incoming value are deeply equal to each other, then we can safely reuse the existing value to avoid needlessly altering references in the cache. Exception B: The application developer can provide custom field merge functions, e.g. for paginating array-valued fields. Since this level of customization was not possible in Apollo Client 2.x, some amount of automatic merging was necessary, but we can do the right thing now that the developer has more control. I am happy that I did not have to update very many tests as a result of these changes, but the principles above are so important that I absolutely would have corrected as many tests as necessary to accommodate these changes.
- Loading branch information
Showing
8 changed files
with
80 additions
and
108 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.