Fix type policy inheritance involving fuzzy possibleTypes

[benjamn]

In #10599 I suggested two typical/supported ways of configuring entity identification: keyFields: [...] (preferred, __typename-specific) and defining a dataIdFromObject function (legacy, catch-all).

Unless you can enforce a blanket assumption that all your types must have a single id field (unlikely, brittle), both approaches ultimately require listing the __typenames of all the types whose keyFields you want to configure, which can be annoying if your application uses many different entity types.

The good news: I think I've found a way to combine a few different InMemoryCache features to achieve a blanket keyFields policy without enumerating all the relevant __typename strings. This approach combines the following features:

• Type policy inheritance (Support inheritance of typePolicies, according to possibleTypes. #7065, Type policy inheritance #9905) allows a supertype (EntitySupertype below) to define a single keyFields: ["uid"] configuration that subtypes can either inherit or override with their own definitions, according to possibleTypes.
• "Fuzzy" possibleTypes (Bring back heuristic fragment matching, with a twist. #6901) are capable of defining supertype-subtype relationships based on RegExp patterns in the subtype name strings (such as EntitySupertype: [".*Entity"] below), so the subtype strings are not required to match any known __typename exactly.

With these two existing features combined, EntitySupertype can define keyFields: ["uid"] just once (using uid instead of id here to make sure we aren't accidentally relying on default id behavior), and then any __typename that ends with Entity should automatically inherit that same keyFields configuration, even if the type has no other type/field policies defined.

Note that EntitySupertype is a made-up client-side type, and does not necessarily need to exist in your schema, though if you already have a common supertype that would work (like Node), I would recommend reusing that existing type instead of making up a new one.

Picking ".*Entity" as a naming convention is obviously an opinionated choice, not appropriate for all schemas and types, but you can use several different patterns, as well as exact __typename strings, so hopefully there's enough flexibility here to make EntitySupertype cover all/most of your entity types.

The bad news: this story was slightly broken, since it implicitly required subtypes to have some type/field policy configuration in order to be capable of inheriting from EntitySupertype. You could go through and add empty type policies for the relevant subtypes, but that brings back the chore of manually enumerating all relevant __typename strings.

Neither of these InMemoryCache features is new, and both are definitely on the obscure side, but it's important to me to keep all existing features working as intended (unless we decide to remove them in a major version), no matter how obscure they may be.

[benjamn]

Although this may still look like a lot of boilerplate, the key point is that we don't need any mention of subtypes like CoworkerEntity or ManagerEntity in this configuration code.

[jerelmiller]

I'm honored to make it into a test 😆

[jerelmiller]

TIL you can use fuzzy type names for possibleTypes. I'd love if we could add some documentation around that behavior at some point.

Nice work!

[phryneas]

This looks like a very useful pattern - we should definitely get that into the docs!

[alessbell]

Very cool! +1 on getting that pattern into the docs, created an issue here: #10639