chore(merge): fix conflicts

.circleci/config.yml

@@ -3,17 +3,25 @@ version: 2
 jobs:
   Filesize:
     docker:
-      - image: circleci/node:16.13.1
+      - image: cimg/node:18.12.0
     steps:
       - checkout
-      - run: npm run ci:precheck
       - run: npm version
       - run: npm ci
       - run: npm run bundlesize
 
+  Lint:
+    docker:
+      - image: cimg/node:18.12.0
+    steps:
+      - checkout
+      - run: npm version
+      - run: npm ci
+      - run: npm run lint
+
   Tests:
     docker:
-      - image: circleci/node:16.10.0
+      - image: cimg/node:18.12.0
     steps:
       - checkout
       - run: npm run ci:precheck
@@ -29,28 +37,10 @@ jobs:
       - store_artifacts:
           path: reports/junit
 
-  # Ensure that any PR that changes packages has a changeset on it (perhaps
-  # an empty one created with `changeset --empty`).
-  # We run the Changesets job itself on all branches so that we can require
-  # it to pass, but we don't run any steps on the "Version Packages" PRs
-  # themselves.
-  Changesets:
-    docker:
-      - image: circleci/node:16.13.1
-    steps:
-      - checkout
-      - run: npm ci
-      - unless:
-          condition:
-            matches:
-              pattern: "^changeset-release/.+$"
-              value: << pipeline.git.branch >>
-          steps:
-            - run: npm run changeset-check
-
 workflows:
   version: 2
   Build and Test:
     jobs:
       - Filesize
       - Tests
+      - Lint

.eslintrc

@@ -0,0 +1,13 @@
+{
+  "overrides": [
+    {
+      "parser": "@typescript-eslint/parser",
+      "plugins": ["@typescript-eslint"],
+      "files": ["**/__tests__/**/*.[jt]sx", "**/?(*.)+(test).[jt]sx"],
+      "extends": ["plugin:testing-library/react"],
+      "rules": {
+        "testing-library/prefer-user-event": "error"
+      }
+    }
+  ]
+}

.github/PULL_REQUEST_TEMPLATE.md

@@ -20,5 +20,6 @@
 
 ### Checklist:
 
+- [ ] If this PR contains changes to the library itself (not necessary for e.g. docs updates), please include a changeset (see [CONTRIBUTING.md](../CONTRIBUTING.md#changesets))
 - [ ] If this PR is a new feature, please reference an issue where a consensus about the design was reached (not necessary for small changes)
 - [ ] Make sure all of the significant new logic is covered by tests

.github/workflows/release.yml

@@ -40,11 +40,15 @@ jobs:
         uses: changesets/action@v1
         with:
           version: npm run changeset-version
-          publish: npm run changeset-publish
+          publish: npm run changeset-publish -- --tag next
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
 
+      - name: Echo values from changesets step
+        if: steps.changesets.outcome == 'success'
+        run: echo "${{steps.changesets.outcome}} v${{ fromJson(steps.changesets.outputs.publishedPackages)[0].version }}"
+
       - name: Send a Slack notification on publish
         if: steps.changesets.outcome == 'success' && steps.changesets.outputs.published == 'true'
         id: slack
@@ -56,6 +60,6 @@ jobs:
           # a comma-delimited list of channel IDs
           channel-id: 'C01PS0CB41G'
           # For posting a simple plain text message
-          slack-message: "Published @apollo/client v${{ fromJson(steps.changesets.outputs.publishedPackages)[0].version }}"
+          slack-message: "Published v${{ fromJson(steps.changesets.outputs.publishedPackages)[0].version }}"
         env:
           SLACK_BOT_TOKEN: ${{ secrets.SLACK_BOT_TOKEN }}

ROADMAP.md

@@ -1,6 +1,6 @@
 # 🔮 Apollo Client Roadmap
 
-**Last updated: Dec 2022**
+**Last updated: Jan 2023**
 
 For up to date release notes, refer to the project's [Change Log](https://github.com/apollographql/apollo-client/blob/main/CHANGELOG.md).
 
@@ -14,26 +14,24 @@ For up to date release notes, refer to the project's [Change Log](https://github
 ---
 
 ## 3.8
-`Release 3.8` will be a series of Alpha releases introducing React 18 & SSR `experimental` features so they can be tested and adopted incrementally.  Eventually these features will be moving to Beta and then to RC and GA release status.
 
-- Adding a new hook `useSuspenseQuery` which will provide the core functionality for React 18 `Suspense` capabilities.
-- Adding support for `Suspense` to `@defer`.
-- Introducing another new hook `useBackgroundQuery` with `Suspense` support.
-- Updating `useFragment` with `Suspense` support.
-- Offer support for React 18's `SSR` `renderToPipeableStream`
+Currently in active development and being shipped in a series alpha releases.  React 18 users will get a lot out of this release since it introduces support for Suspense and (for you server-side rendering enthusiasts) `renderToPipeableStream`.  There are also new features added to the core as well.  Here's a brief overview:
 
-As we release each new feature we'll be looking for feedback from the community on performance, usage and developer experience of adopting and implementing these new concepts in your applications.
+- Add a new hook `useSuspenseQuery` which will provide the core functionality for React 18 `Suspense` capabilities
+- Ability to use `Suspense` with `@defer`
+- Introduce another new hook `useBackgroundQuery` with `Suspense` support
+- Ability to use `Suspense` with  `useFragment`
+- Server-side rendering (SSR) upgrade: support `renderToPipeableStream` for streaming renders
+- Add the (opt-in) ability to access fields with the `@client` directive in the link chain
 
-See Github [3.8 Milestone](https://github.com/apollographql/apollo-client/milestone/30) for more details.
+As we release each new feature we'll be looking for feedback from the community on performance, usage and developer experience of adopting and implementing these new concepts in your applications.  Try it today: `npm i @apollo/client@alpha` and let us know what you think!  Once new feature development is complete we'll move this to beta and then GA once stable.
 
-## 3.9
+See the [3.8 Milestone](https://github.com/apollographql/apollo-client/milestone/30) for more details.
 
-- TBD
+## Future 3.x releases
 
-## 3.10
-
-- TBD
+The 3.8 release is a major milestone for the project's React support.  Feedback from the community will have a big impact on where we go next, particularly as use cases for React Server Components and other React 18 features emerge.  In addition to new functionality, there is a significant backlog of questions and fixes that we want to categorize and thoughtfully address in upcoming releases.
 
 ## 4.0
 
-- `Release 4.0` will be our next major release of the Client and is still in `pre-planning` phases. See Github [4.0 Milestone](https://github.com/apollographql/apollo-client/milestone/31) for more details.
+- `Release 4.0` will be our next major release of the Client and is still in early planning.  See Github [4.0 Milestone](https://github.com/apollographql/apollo-client/milestone/31) for more details.

config/jest.config.js

@@ -37,8 +37,6 @@ const react18TestFileIgnoreList = [
   // to avoid running them twice with both react versions
   // since they do not import react
   ignoreTSFiles,
-  // failing subscriptionLink test (1)
-  'src/testing/react/__tests__/mockSubscriptionLink.test.tsx',
   // failing hoc tests (8)
   'src/react/hoc/__tests__/mutations/queries.test.tsx',
   'src/react/hoc/__tests__/mutations/recycled-queries.test.tsx',
@@ -48,15 +46,7 @@ const react18TestFileIgnoreList = [
   'src/react/hoc/__tests__/queries/observableQuery.test.tsx',
   'src/react/hoc/__tests__/queries/skip.test.tsx',
   'src/react/hoc/__tests__/subscriptions/subscriptions.test.tsx',
-  // failing hooks tests (4)
-  'src/react/hooks/__tests__/useMutation.test.tsx',
-  'src/react/hooks/__tests__/useQuery.test.tsx',
-  'src/react/hooks/__tests__/useReactiveVar.test.tsx',
-  'src/react/hooks/__tests__/useSubscription.test.tsx',
-  // failing components tests (4)
-  'src/react/components/__tests__/ssr/server.test.tsx',
-  'src/react/components/__tests__/client/Subscription.test.tsx',
-  'src/react/components/__tests__/client/Mutation.test.tsx',
+  // failing components tests (1)
   'src/react/components/__tests__/client/Query.test.tsx',
 ];
 

docs/source/config.json

@@ -16,7 +16,7 @@
       "Refetching": "/data/refetching",
       "Subscriptions": "/data/subscriptions",
       "Fragments": "/data/fragments",
-      "@defer support (preview)": "/data/defer",
+      "@defer support": "/data/defer",
       "Error handling": "/data/error-handling",
       "Best practices": "/data/operation-best-practices"
     },

docs/source/data/defer.mdx

@@ -3,15 +3,17 @@ title: "Using the @defer directive in Apollo Client"
 description: Receive query response data incrementally
 ---
 
-> ⚠️ **The `@defer` directive is currently at the [preview stage](/resources/product-launch-stages/#preview) in Apollo Client, and is available by installing `@apollo/client@latest`.** If you have feedback on it, please let us know via [GitHub issues](https://github.com/apollographql/apollo-client/issues/new?assignees=&labels=&template=bug.md).
+> **The `@defer` directive is currently at the [General Availability stage](/resources/product-launch-stages/#general-availability) in Apollo Client, and is available by installing `@apollo/client@latest`.** If you have feedback on it, please let us know via [GitHub issues](https://github.com/apollographql/apollo-client/issues/new?assignees=&labels=&template=bug.md).
 
 Beginning with version `3.7.0`, Apollo Client Web provides preview support for [the `@defer` directive](https://github.com/graphql/graphql-wg/blob/main/rfcs/DeferStream.md). This directive enables your queries to receive data for specific fields _incrementally_, instead of receiving all field data at the same time. This is helpful whenever some fields in a query take much longer to resolve than others.
 
-> For a query to defer fields successfully, the queried endpoint must _also_ support the `@defer` directive.
+> For a query to defer fields successfully, the queried endpoint must _also_ support the `@defer` directive. Entity-based `@defer` support is also at the General Availability stage in [Apollo Router](/router/executing-operations/defer-support/) and is compatible with all [federation-compatible subgraph libraries](/federation/building-supergraphs/supported-subgraphs/).
 
 ## Example
 
-Let's say we're building a social media application that can quickly fetch a user's basic profile information, but retrieving that user's friends takes longer. If we include _all_ of those fields in a single query, we want to be able to display the profile information as soon as it's available, instead of waiting for the friend fields to resolve.
+Let's say we're building a social media application that can quickly fetch a user's basic profile information, but retrieving that user's friends takes longer.
+
+GraphQL allows us to declare all the fields our UI requires in a single query, but this also means that _our query will be as slow as the field that takes the longest to resolve_. The `@defer` directive allows us to mark parts of the query that are not necessary for our app's initial render which will be resolved once it becomes available.
 
 To achieve this, we apply the `@defer` directive to an in-line fragment that contains all slow-resolving fields related to friend data:
 
@@ -37,6 +39,43 @@ query PersonQuery($personId: ID!) {
 
 Using this syntax, _if the queried server supports `@defer`,_ our client can receive the "Basic fields" in an initial response payload, followed by a supplementary payload containing the "Friend fields".
 
+Let's look at an example in React. Here's we can assume `GET_PERSON` is the above query, `PersonQuery`, with a deferred list of friends' `id`s:
+
+```tsx title="index.js"
+import { gql, useQuery } from "@apollo/client";
+
+function App() {
+  const { loading, error, data } = useQuery(GET_PERSON, {
+    variables: {
+      id: 1,
+    },
+  });
+
+  if (loading) return "Loading...";
+  if (error) return `Error! ${error.message}`;
+
+  return (
+    <>
+      Welcome, {data.firstName} {data.lastName}!
+      <details>
+        <summary>Friends list</summary>
+        {data.friends ? (
+          <ul>
+            {data.friends.map((id) => (
+              <li>{id}</li>
+            ))}
+          </ul>
+        ) : null}
+      </details>
+    </>
+  );
+}
+```
+
+When our call to the `useQuery` hook first resolves with an initial payload of data, `loading` will go from `true` to `false` and `firstName` and `lastName` will be populated with the values from the server. **Our deferred fields will not exist as keys on `data` yet**, so we must add conditional logic that checks for their presence. When subsequent chunks of deferred data arrive, `useQuery` will re-render (`loading` remains `false` between re-renders from deferred multipart responses) and `data` will include the deferred data as they arrive.
+
+For this reason, `@defer` can be thought of as a tool to improve initial rendering speeds when some slower data will be displayed below the fold or offscreen. In this case, we're rendering the friends list inside a `<details>` element which is closed by default, avoiding any layout shift as the `friends` data arrives.
+
 ## Using with code generation
 
 If you currently use [GraphQL Code Generator](https://www.the-guild.dev/graphql/codegen) for your codegen needs, note that it doesn't yet support the use of the `@defer` directive in the code output.

netlify.toml

@@ -7,7 +7,7 @@
 
 [context.deploy-preview.build]
   base = "docs"
-  ignore = "git diff --quiet HEAD^ HEAD ."
+  ignore = "exit 1"
   command = """\
   cd ../
   rm -rf monodocs