Merge branch 'master' into bugfix/deduplication-from-request

.vscode/launch.json

@@ -2,17 +2,21 @@
   "version": "0.2.0",
   "configurations": [
     {
-      "name": "Test",
-      "request": "launch",
       "type": "node",
-      "program":
-        "${workspaceRoot}/packages/apollo-client/node_modules/jest/bin/jest.js",
-      "internalConsoleOptions": "openOnSessionStart",
-      "stopOnEntry": false,
-      "args": ["-i"],
-      "cwd": "${workspaceRoot}/packages/apollo-client",
-      "sourceMaps": true,
-      "outFiles": ["${workspaceRoot}/lib/**/*"]
+      "request": "launch",
+      "name": "Jest Current File",
+      "program": "${workspaceFolder}/node_modules/.bin/jest",
+      "args": [
+        "${fileBasenameNoExtension}",
+        "--config",
+        "./config/jest.config.js"
+      ],
+      "console": "integratedTerminal",
+      "internalConsoleOptions": "neverOpen",
+      "disableOptimisticBPs": true,
+      "windows": {
+        "program": "${workspaceFolder}/node_modules/jest/bin/jest",
+      }
     }
   ]
 }

CHANGELOG.md

@@ -41,7 +41,7 @@
 - **[BREAKING]** `InMemoryCache` now _throws_ when data with missing or undefined query fields is written into the cache, rather than just warning in development. <br/>
   [@benjamn](https://github.com/benjamn) in [#6055](https://github.com/apollographql/apollo-client/pull/6055)
 
-- **[BREAKING]** The `client|cache.writeData` methods have been fully removed, as `writeData` is one of the easiest ways to turn faulty assumptions about how the cache represents data internally into cache inconsistency and corruption. Instead, use `client|cache.writeQuery` or `client|cache.writeFragment` to update the cache. <br/>
+- **[BREAKING]** `client|cache.writeData` have been fully removed. `writeData` usage is one of the easiest ways to turn faulty assumptions about how the cache represents data internally, into cache inconsistency and corruption. `client|cache.writeQuery`, `client|cache.writeFragment`, and/or `cache.modify` can be used to update the cache.  <br/>
   [@benjamn](https://github.com/benjamn) in [#5923](https://github.com/apollographql/apollo-client/pull/5923)
 
 - **[BREAKING]** Apollo Client will no longer deliver "stale" results to `ObservableQuery` consumers, but will instead log more helpful errors about which cache fields were missing. <br/>
@@ -56,18 +56,19 @@
 - **[BREAKING?]** Refactor `QueryManager` to make better use of observables and enforce `fetchPolicy` more reliably. <br/>
   [@benjamn](https://github.com/benjamn) in [#6221](https://github.com/apollographql/apollo-client/pull/6221)
 
-- **[beta-BREAKING]** The experimental `cache.modify` method, first introduced in [PR #5909](https://github.com/apollographql/apollo-client/pull/5909), has been removed. <br/>
-  [@benjamn](https://github.com/benjamn) in [#6289](https://github.com/apollographql/apollo-client/pull/6289)
-
 - `InMemoryCache` now supports tracing garbage collection and eviction. Note that the signature of the `evict` method has been simplified in a potentially backwards-incompatible way. <br/>
   [@benjamn](https://github.com/benjamn) in [#5310](https://github.com/apollographql/apollo-client/pull/5310)
 
-- The `cache.evict` method can optionally take an arguments object as its third parameter (following the entity ID and field name), to delete only those field values with specific arguments. <br/>
+- **[beta-BREAKING]** Please note that the `cache.evict` method now requires `Cache.EvictOptions`, though it previously supported positional arguments as well. <br/>
   [@danReynolds](https://github.com/danReynolds) in [#6141](https://github.com/apollographql/apollo-client/pull/6141)
+  [@benjamn](https://github.com/benjamn) in [#6364](https://github.com/apollographql/apollo-client/pull/6364)
 
 - Cache methods that would normally trigger a broadcast, like `cache.evict`, `cache.writeQuery`, and `cache.writeFragment`, can now be called with a named options object, which supports a `broadcast: boolean` property that can be used to silence the broadcast, for situations where you want to update the cache multiple times without triggering a broadcast each time. <br/>
   [@benjamn](https://github.com/benjamn) in [#6288](https://github.com/apollographql/apollo-client/pull/6288)
 
+- `InMemoryCache` now `console.warn`s in development whenever non-normalized data is dangerously overwritten, with helpful links to documentation about normalization and custom `merge` functions. <br/>
+  [@benjamn](https://github.com/benjamn) in [#6372](https://github.com/apollographql/apollo-client/pull/6372)
+
 - The contents of the `@apollo/react-hooks` package have been merged into `@apollo/client`, enabling the following all-in-one `import`:
   ```ts
   import { ApolloClient, ApolloProvider, useQuery } from '@apollo/client';
@@ -89,6 +90,21 @@
 - The result caching system (introduced in [#3394](https://github.com/apollographql/apollo-client/pull/3394)) now tracks dependencies at the field level, rather than at the level of whole entity objects, allowing the cache to return identical (`===`) results much more often than before. <br/>
   [@benjamn](https://github.com/benjamn) in [#5617](https://github.com/apollographql/apollo-client/pull/5617)
 
+- `InMemoryCache` now has a method called `modify` which can be used to update the value of a specific field within a specific entity object:
+  ```ts
+  cache.modify({
+    id: cache.identify(post),
+    fields: {
+      comments(comments: Reference[], { readField }) {
+        return comments.filter(comment => idToRemove !== readField("id", comment));
+      },
+    },
+  });
+  ```
+  This API gracefully handles cases where multiple field values are associated with a single field name, and also removes the need for updating the cache by reading a query or fragment, modifying the result, and writing the modified result back into the cache. Behind the scenes, the `cache.evict` method is now implemented in terms of `cache.modify`. <br/>
+  [@benjamn](https://github.com/benjamn) in [#5909](https://github.com/apollographql/apollo-client/pull/5909)
+  and [#6178](https://github.com/apollographql/apollo-client/pull/6178)
+
 - `InMemoryCache` provides a new API for storing client state that can be updated from anywhere:
   ```ts
   const v = cache.makeVar(123)
@@ -141,14 +157,18 @@
 - Make sure `ApolloContext` plays nicely with IE11 when storing the shared context.  <br/>
   [@ms](https://github.com/ms) in [#5840](https://github.com/apollographql/apollo-client/pull/5840)
 
-- Expose `cache.identify` to the mutation `update` function. <br/>
+- Expose cache `modify` and `identify` to the mutate `update` function.  <br/>
   [@hwillson](https://github.com/hwillson) in [#5956](https://github.com/apollographql/apollo-client/pull/5956)
 
 - Add a default `gc` implementation to `ApolloCache`.  <br/>
   [@justinwaite](https://github.com/justinwaite) in [#5974](https://github.com/apollographql/apollo-client/pull/5974)
 
 - Updated to work with `graphql@15`.  <br/>
-  [@durchanek](https://github.com/durchanek) in [#6194](https://github.com/apollographql/apollo-client/pull/6194) and [#6279](https://github.com/apollographql/apollo-client/pull/6279)
+  [@durchanek](https://github.com/durchanek) in [#6194](https://github.com/apollographql/apollo-client/pull/6194) and [#6279](https://github.com/apollographql/apollo-client/pull/6279) <br/>
+  [@hagmic](https://github.com/hagmic) in [#6328](https://github.com/apollographql/apollo-client/pull/6328)
+
+- Apollo Client now supports setting a new `ApolloLink` (or link chain) after `new ApolloClient()` has been called, using the `ApolloClient#setLink` method.  <br/>
+  [@hwillson](https://github.com/hwillson) in [#6193](https://github.com/apollographql/apollo-client/pull/6193)
 
 ### Bug Fixes
 

config/rollup.config.js

@@ -63,6 +63,39 @@ function prepareCJS(input, output) {
     },
     plugins: [
       nodeResolve(),
+      // When generating the `dist/core/core.cjs.js` entry point (in
+      // `config/prepareDist.js`), we filter and re-export the exports we
+      // need from the main Apollo Client CJS bundle (to exclude React related
+      // code). This means that consumers of `core.cjs.js` attempt to load the
+      // full AC CJS bundle first (before filtering exports), which then means
+      // the React require in the AC CJS bundle is attempted and not found
+      // (since people using `core.cjs.js` want to use Apollo Client without
+      // React). To address this, we make React an optional require in the CJS
+      // bundle.
+      (() => {
+        const cjsBundle = output.replace(`${distDir}/`, '');
+        return {
+          generateBundle(_option, bundle) {
+            const parts = bundle[cjsBundle].code.split(
+              /var React = require\('react'\);/);
+            // The React import should appear only once in the CJS bundle,
+            // since we build the CJS bundle using Rollup, which (hopefully!)
+            // deduplicates all external imports.
+            if (parts && parts.length === 2) {
+              bundle[cjsBundle].code = [
+                parts[0],
+                "try { var React = require('react'); } catch (error) {}",
+                parts[1],
+              ].join("\n");
+            } else {
+              throw new Error(
+                'The CJS bundle could not be prepared as a single React ' +
+                'require could not be found.'
+              );
+            }
+          }
+        }
+      })()
     ],
   };
 }

docs/package.json

@@ -14,6 +14,6 @@
   },
   "devDependencies": {
     "typedoc": "0.15.6",
-    "typescript": "3.7.4"
+    "typescript": "3.9.3"
   }
 }

docs/source/api/react/hoc.mdx

@@ -727,7 +727,7 @@ export default graphql(gql`query MyQuery { ... }`, {
 
 ### `options.context`
 
-With the flexiblity and power of [Apollo Link](../../networking/advanced-http-networking/) being part of Apollo Client, you may want to send information from your operation straight to a link in your network chain! This can be used to do things like set `headers` on HTTP requests from props, control which endpoint you send a query to, and so much more depending on what links your app is using. Everything under the `context` object gets passed directly to your network chain. For more information about using context, check out the [`HttpLink` context docs](../../networking/advanced-http-networking/)
+With the flexibility and power of [Apollo Link](../../networking/advanced-http-networking/) being part of Apollo Client, you may want to send information from your operation straight to a link in your network chain! This can be used to do things like set `headers` on HTTP requests from props, control which endpoint you send a query to, and so much more depending on what links your app is using. Everything under the `context` object gets passed directly to your network chain. For more information about using context, check out the [`HttpLink` context docs](../../networking/advanced-http-networking/)
 
 ### `partialRefetch`
 

docs/source/caching/cache-configuration.md

@@ -148,7 +148,8 @@ A `TypePolicy` object can include the following fields:
 ```ts
 type TypePolicy = {
   // Allows defining the primary key fields for this type, either using an
-  // array of field names or a function that returns an arbitrary string.
+  // array of field names, a function that returns an arbitrary string, or
+  // false to disable normalization for objects of this type.
   keyFields?: KeySpecifier | KeyFieldsFunction | false;
 
   // If your schema uses a custom __typename for any of the root Query,

docs/source/data/local-state.mdx

@@ -176,13 +176,13 @@ const client = new ApolloClient({
   resolvers: {
     Mutation: {
       toggleTodo: (_root, variables, { cache }) => {
-        const id = cache.identify({
-          __typename: 'TodoItem',
-          id: variables.id,
-        });
-        cache.modify(id, {
-          completed(value) {
-            return !value;
+        cache.modify({
+          id: cache.identify({
+            __typename: 'TodoItem',
+            id: variables.id,
+          }),
+          fields: {
+            completed: value => !value,
           },
         });
         return null;
@@ -621,7 +621,7 @@ const client = new ApolloClient({
 });
 ```
 
-[`CameraRoll.getPhotos()`](https://facebook.github.io/react-native/docs/cameraroll.html#getphotos) returns a `Promise` resolving to an object with a `edges` property, which is an array of camera node objects, and a `page_info` property, which is an object with pagination information. This is a great use case for GraphQL, since we can filter down the return value to only the data that our components consume.
+[`CameraRoll.getPhotos()`](https://facebook.github.io/react-native/docs/cameraroll.html#getphotos) returns a `Promise` resolving to an object with an `edges` property, which is an array of camera node objects, and a `page_info` property, which is an object with pagination information. This is a great use case for GraphQL, since we can filter down the return value to only the data that our components consume.
 
 ```js
 import { gql } from "@apollo/client";
@@ -1095,7 +1095,7 @@ const client = new ApolloClient({
 };
 ```
 
-The `cache.writeQuery` and `cache.writeFragment` methods should cover most of your needs; however, there are some cases where the data you're writing to the cache depends on the data that's already there. In that scenario, you should use `cache.modify(id, modifiers)` to update specific fields within the entity object identified by `id`.
+The `cache.writeQuery` and `cache.writeFragment` methods should cover most of your needs; however, there are some cases where the data you're writing to the cache depends on the data that's already there. In that scenario, you can either use a combination of `cache.read{Query,Fragment}` followed by `cache.write{Query,Fragment}`, or use `cache.modify({ id, fields })` to update specific fields within the entity object identified by `id`.
 
 ### writeQuery and readQuery
 

docs/source/data/mutations.mdx

@@ -298,7 +298,9 @@ The following sample illustrates defining an update function in a call to `useMu
 ```jsx
 const GET_TODOS = gql`
   query GetTodos {
-    todos
+    todos {
+      id
+    }
   }
 `;
 

docs/source/development-testing/testing.mdx

@@ -7,7 +7,7 @@ import { MultiCodeBlock } from 'gatsby-theme-apollo-docs';
 
 Running tests against code meant for production has long been a best practice. It provides additional security for the code that's already written, and prevents accidental regressions in the future. Components utilizing React with Apollo Client are no exception.
 
-Although Apollo Client's React integration has a lot going on under the hood, the library provides multiple tools for testing that simplify those abstractions, and allows complete focus on the component logic. These testing utilities have long been used to test React functoinality with Apollo Client itself, so they will be supported long-term.
+Although Apollo Client's React integration has a lot going on under the hood, the library provides multiple tools for testing that simplify those abstractions, and allows complete focus on the component logic. These testing utilities have long been used to test React functionality with Apollo Client itself, so they will be supported long-term.
 
 ## An introduction