In Apollo Client 4, the Author type has no id and is identified by a unique handle; how do you make InMemoryCache normalize it?

## Why the default ID is not enough `InMemoryCache` identifies objects with a function called `defaultDataIdFromObject`, which reads `__typename` and then `id`, falling back to `_id`. When a type is identified by something else, such as an author's unique `handle`, that function returns nothing and the cache stores each author **inline** inside every post that mentions it. Renames and other updates then stop propagating across the feed. The symptom is easy to miss: nothing errors and the feed renders, and only a later write to one author reveals that each post holds its own copy. `cache.extract()` shows it directly, as posts whose `author` field contains a full object instead of a `__ref`. The fix is a **type policy**: per-type configuration passed to `InMemoryCache` through the `typePolicies` option, keyed by `__typename`. ## Declaring keyFields The `keyFields` property of a type policy says which fields identify an object of that type: ```ts import { InMemoryCache } from "@apollo/client"; const cache = new InMemoryCache({ typePolicies: { Author: { keyFields: ["handle"] }, }, }); ``` With this policy the author with handle `ada` is stored under the cache ID `Author:{"handle":"ada"}`: the type name, a colon, and a JSON object of the key fields. Things to know about how this works: - **Schema names, not aliases.** `keyFields` refers to the field names in the schema, so a query that aliases `handle` as `username` still produces the same ID. - **Stable order.** With several key fields, the ID always lists them in the order declared, so the same object always gets the same ID. - **The key must be selected.** If a result contains an Author without `handle`, the write fails with an invariant error, `Missing field 'handle' while extracting keyFields from …`. It does not silently store a second copy. - **`cache.identify` follows the policy.** `cache.identify({ __typename: "Author", handle: "ada" })` returns the same ID the cache uses, which saves you from building JSON-shaped IDs by hand for `cache.modify` or `cache.evict`. ## The other forms keyFields takes | Value | Example | Effect | |---|---|---| | array of fields | `["handle"]` | ID built from those fields | | several fields | `["platform", "handle"]` | composite key, both required | | nested field | `["title", "author", ["handle"]]` | uses a field of a child object | | empty array | `[]` | singleton: one object of the type, ID `FeedSettings:{}` | | `false` | `false` | normalization off; objects stay inline in their parent | | function | `(object, context) => …` | returns an ID string or a key array | The function form receives the object and a context with `typename`, `storeObject` and `readField`. The documentation recommends reading from `context.storeObject` or `context.readField`, which are already de-aliased, rather than from the raw object. ## dataIdFromObject: the global fallback `InMemoryCache` also accepts a `dataIdFromObject` option: one function that computes IDs for every type. It dates from Apollo Client 2 and remains for migration. A type policy's `keyFields` wins over it for its type; types without one fall back to it. The documentation lists its drawbacks: 1. It is sensitive to aliasing mistakes, because it sees the raw result object. 2. It does nothing to protect against undefined properties, so a missing field can produce an ID such as `Author:undefined`. 3. Using different key fields at different times causes inconsistent IDs. For these reasons, per-type `keyFields` arrays are the recommended way to key a type by a custom field. ## Sharing a key across related types If the feed's `Author` and `Page` types both implement an `Actor` interface and share the `handle` key, you can declare `possibleTypes: { Actor: ["Author", "Page"] }` on the cache and put `keyFields: ["handle"]` on `Actor` once. Type policies are inherited from supertypes named in `possibleTypes`, so both subtypes use the same key without repeating it. ## Checklist when introducing a custom key 1. Add the type policy with `keyFields` before shipping queries that rely on it. 2. Make sure every query, fragment and mutation result that returns the type selects the key field. 3. Use `cache.identify` in update code instead of formatting IDs yourself. 4. Check `cache.extract()` to confirm the type now appears as `Author:{"handle":…}` entities rather than embedded objects. 5. Remove any `dataIdFromObject` branch that used to handle the type, so exactly one place defines its key.