Support inheritance of typePolicies, according to possibleTypes.

[benjamn]

Motivating discussion: #6949 (comment)

JavaScript developers will be familiar with the idea of inheritance from the extends clause of class declarations, or possibly from dealing with prototype chains created by Object.create.

Here's how type policy inheritance works for InMemoryCache:

const cache = new InMemoryCache({
  possibleTypes: {
    Reptile: ["Snake", "Turtle"],
    Snake: ["Python", "Viper", "Cobra"],
    Viper: ["Cottonmouth", "DeathAdder"],
  },

  typePolicies: {
    Reptile: {
      // Suppose all our reptiles are captive, and have a tag with an ID.
      keyFields: ["tagId"],
      fields: {
        // Scientific name-related logic can be shared among Reptile subtypes.
        scientificName: {
          merge(_, incoming) {
            // Normalize all scientific names to lower case.
            return incoming.toLowerCase();
          },
        },
      },
    },

    Snake: {
      fields: {
        // Default to a truthy non-boolean value if we don't know
        // whether this snake is venomous.
        venomous(status = "unknown") {
          return status;
        },
      },
    },
  },
});

Inheritance is a powerful code-sharing tool, and it works well for Apollo Client for several reasons:

1. InMemoryCache already knows about the supertype-subtype relationships (interfaces and unions) in your schema, thanks to possibleTypes, so no additional configuration is necessary to provide that information.

2. Inheritance allows a supertype to provide default configuration values to all its subtypes, including keyFields and individual field policies, which can be selectively overridden by subtypes that want something different.

3. A single subtype can have multiple supertypes in a GraphQL schema, which is difficult to model using the single inheritance model of classes or prototypes. In other words, supporting multiple inheritance in JavaScript requires building a system something like this one, rather than just reusing built-in language features.

4. Developers can add their own client-only supertypes to the possibleTypes map, as a way of reusing behavior across types, even if their schema knows nothing about those made-up supertypes.

5. The possibleTypes map is currently used only for fragment matching purposes, which is an important but fairly small part of what the client does. Inheritance adds another compelling use for possibleTypes, and should drastically reduce repetition of typePolicies when used effectively.

Inheritance is a step back (in terms of freedom/power) from the completely dynamic policyForType and policyForField functions I proposed in #6808 (comment), but I think inheritable typePolicies can address most of the concerns raised in #6808.

[vigie]

Thanks for working on this. In your example, could you explain what would happen if Snake also declares a field policy for scientificName?

[hwillson]

Wow, in the end this turned out to be a surprisingly small amount of code changes, thanks to the policy internals. This looks awesome! Your PR description is also incredibly helpful - I think it could be added to the docs almost exactly as it is?

[hwillson]

@vigie subtype field policies override supertype field policies, with the same name. So a Snake scientificName field policy will override the Reptile scientificName field policy.

[benjamn]

Added a comment about policy precedence and the handling of inherited field policies.

[vigie]

OK, so if I'm reading this correctly descendant definitions just clobber their ancestor definitions. That's clear and simple.

I'm curious whether you considered running the definitions in sequence, passing the result of each as the input to the next, kind of like the way a constructor chain would work in OO?