In Apollo Client 4, how do you add a locally computed isInCart field to a server Product queried alongside its name and price?

## What a local-only field is A **local-only field** is a field your query selects that the GraphQL server does not define. You mark it with the `@client` directive, and Apollo Client computes its value in the browser. The point is that one query can return server data and client data together, so a product page reads `name`, `price` and `isInCart` from a single `data.product` object instead of stitching two sources together in the component. ## The three pieces 1. **The query.** Select the field with `@client`, and select `id` too, because the local computation needs it: ```graphql query ProductPage($id: ID!) { product(id: $id) { id name price isInCart @client } } ``` 2. **A field policy with a `read` function.** In `InMemoryCache`'s `typePolicies`, `Product.fields.isInCart.read` returns the value. Its second argument carries helpers; `readField("id")` reads another field of the same `Product` object from the cache. The function then checks that id against `cartItemIdsVar()`, a reactive variable created with `makeVar<string[]>([])`. 3. **`LocalState` on the client.** Since Apollo Client 4.0, `@client` support is not built into the core. You pass `localState: new LocalState()`, imported from `@apollo/client/local-state`, to `new ApolloClient`. A `LocalState` with no resolvers is enough when every local field is served by a `read` function. Without it the query throws, and development builds name the cause: the operation contains `@client` fields but local state has not been configured. ## What happens when the query runs | Step | What Apollo does | |---|---| | Before the request | removes `isInCart` from the document; a query made only of `@client` fields sends no request at all | | Server responds | writes `id`, `name` and `price` to the `Product` entity in the cache | | Result is read | reads the entity back; for `isInCart` it calls the `read` function instead of looking for a stored value | | Hook delivers | `data.product` contains all four fields | Nothing is written for `isInCart`: the value is computed each time the cached result is recomputed, from whatever the cart holds at that moment. ## Why it stays current Inside a `read` function, reading a reactive variable is tracked. Apollo remembers that `Product.isInCart` depends on `cartItemIdsVar`. When an "Add to cart" button calls `cartItemIdsVar([...cartItemIdsVar(), product.id])`, Apollo invalidates the cached results that used that field and re-delivers every active query selecting it. The product page, a search result list and a recommendations strip that select the field all flip to "In cart" without a refetch, because none of them depended on the server for that bit. The same would not happen if the read function looked at a plain module-level array: Apollo cannot see a change it was never told about. If the local value lives somewhere Apollo does not track, you must trigger the refresh yourself. ## Edge cases worth knowing - **Read functions are synchronous.** They must return a value immediately; asynchronous lookups belong in a `LocalState` resolver instead. - **`no-cache` bypasses them.** A query run with `fetchPolicy: "no-cache"` does not read the cache, so a field served only by a `read` function comes back `null`; since 4.1 Apollo also warns about it. A `LocalState` resolver for the field avoids that. - **Nested selections.** Putting `@client` on a field with a sub-selection makes the whole sub-selection local. - **Local values as variables.** A `@client` field can feed a variable of the same query with `@export(as: "name")`, as long as it appears before the fields that use the variable. - **`@client` and `@defer` cannot share an operation**; Apollo throws when a document contains both. ## Why not write the value onto the entity An alternative is to store `isInCart` on each cached `Product` yourself, writing it with `cache.writeFragment` whenever the cart changes. It works, but it turns a derived value into a copy: every add, remove and cart reset must find and update every affected product, including ones loaded later. The `read` function avoids that bookkeeping because it computes the value from the current cart each time the field is read. ## Why interviewers ask it The question tests whether a candidate knows the current wiring (the 4.x `LocalState` opt-in trips most people who learned on 3.x) and whether they understand that a `read` function turns local state into a derived, reactive field on a server entity rather than a copy that must be kept in sync by hand.