This reverts commit 60e18e9 from PR #8396.

…e-3.6.

Merging into `release-3.6` before merging into `main` so we can do some
additional testing with beta releases.

* add use-sync-external-store

* Initial work on using useSyncExternalStore

* fix useLazyQuery tests

* update use-sync-external-store version

* update timings to useMutation tests

* change the timing in a Mutation component test which changed for no ostensible reason

* fix the hoc tests agane

* bring back the bad boy code block by popular demand

* update useSyncExternalStore to handle ssr

* use published useSyncExternalStore types

* update dependencies and add beta to react peer range

The specific failure is an integrity hash mismatch:

  5:44:05 PM: npm ERR! code EINTEGRITY
  5:44:05 PM: npm ERR! sha512-yXbYeFy+jUuYd3/CDcg2NkIYE991XYX/bje7LmjJigUciaeO1JR4XxXgCIV1/Zc/dRuFEyw1L0pbA+qynJkW5Q==
                       integrity checksum failed when using sha512: wanted sha512-yXbYeFy+jUuYd3/CDcg2NkIYE991XYX/bje7LmjJigUciaeO1JR4XxXgCIV1/Zc/dRuFEyw1L0pbA+qynJkW5Q==
                       but got sha512-U1riIR+lBSNi3IbxtaHOIKdH8sLFv3NYfNv8sg7ZsNhcfl4HF2++BfqqrNAxoCLQW1iiylOj76ecnaUxz+z9yw==

Example failed deployment (or see any of the recent failures in #9067):
https://app.netlify.com/sites/apollo-client-docs/deploys/619d6dc222deda1694aa37a6

Although the error doesn't mention the package name, I was able to grep
for the expected hash in package-lock.json, which pointed to the `acorn`
package. As you can tell from this commit's changes, the actual hash
displayed above (ending in +z9yw==) happens to be the hash for
[email protected], whereas the expected hash was that of [email protected].

…9112)"

This reverts commit efe61de, which did
not, in fact, prevent the Netlify failures. Instead, updating `acorn`
seems to have been the ticket.

I relaxed the peer dependency version constraint to allow any
1.0.0-compatible version, including betas and RCs.

For local development of the Apollo Client library itself, I added
use-sync-external-store to our devDependencies (like we do with react
and react-dom), since I was seeing `npm i` fail to install
node_modules/use-sync-external-store, perhaps because it is now an
optional peer dep.

After an operation has been subscribed to, and so queued, it is possible
to unsubscribe from it, and it will be removed from the queue.

Unsubscribing will not impact the debounce, so other operations, if any, will
not be delayed by an unsubscription.

If a batch of operation is already in flight, and all operations are unsubscribed
then the entire XHR will be cancelled. If only some operations are unsubscribed
the XHR will be left untouched.

Since BatchHandler is an exported type, it seems appropriate to preserve
its optional fields (with their expected types), then override those
fields (next, error, complete) with non-optional versions in the
QueuedRequest subtype. The field/types of QueuedRequest will end up the
same either way.

Since ECMAScript Set and Map preserve the order of their keys (by order
of first insertion), they can often be used to keep track of queues or
LRU usage chains, while also supporting constant-time deletion of keys
(no need for indexOf/splice).

Since we're already changing the type of this pseudo-private property,
it seems like a good idea also to privatize/rename it for real, so we
can test the hypothesis "nobody is using this field directly" by
trialing these changes in beta releases of Apollo Client v3.6.

Because those are never used inside this project, and they are very
likely to break our indices based callback calls and throw an
`server returned results with length...`.

Apollo Client currently contains `WebSocketLink` in
`@apollo/client/link/ws` which uses the `subscriptions-transport-ws`
library. That library is no longer actively maintained, and there is an
improved fork called `graphql-ws`.

The two libraries use different protocols so a different client link is
required for `graphql-ws`. (While the WebSocket protocol does allow for
subprotocol negotiation, neither server implementation supports this in
a practical way.)

This PR adds a new link `GraphQLWsLink` in
`@apollo/client/link/subscriptions`. Its constructor arguments are the
same as the `createClient` function in `graphql-ws` (or it can take a
`Client` object returned from that function), and you need to install
the optional peer dep `graphql-ws` instead of
`subscriptions-transport-ws`. Once you've created the link, it works
exactly like the old `WebSocketLink`.

This PR changes the main subscriptions doc page to mostly document the
new link, with an extra section at the bottom for the old link.

The core GraphQLWsLink code is based on MIT-licensed code from the
README of the graphql-ws repository.

Fixes #8345.
Part of apollographql/apollo-server#6058

Co-authored-by: Ben Newman <[email protected]>

Co-authored-by: Ben Newman <[email protected]>

New GraphQLWsLink for graphql-ws subscriptions library

Batch link can cancel operations that are in queue or in flight

This reverts commit 7f0d459 (#8785)
and follow-up commit 5328dae (move
onCompleted and onError to the snapshot function).

Should help with issue #8218, thanks to @benmccann's work in
apollographql/invariant-packages#254

…the component re-renders

I will revisit this approach to prevent repeated updates of unchanging
result properties (like obsQueryFields).

Removing result.partial when it's truthy defeats the whole purpose of
this (questionably necessary) field.

…stently.

Follow-up/refinement to PR #9210.

Now that the createWatchQueryOptions function no longer defaults
watchQueryOptions.fetchPolicy to "cache-first" unconditionally (instead
defaulting to defaultOptions.watchQuery.fetchPolicy if defined), we can
let the merging of defaultOptions happen as it normally does, when
client.watchQuery(watchQueryOptions) is called later.

Using options as a useMemo dependency only happens to work here when
options is undefined. If options is an object created fresh every time
useQuery is called (as it often is), the useMemo version of this code
would produce a new watchQueryOptions object on every call.

This handful of test changes all seem defensible to me.

…ery.

TODO Find a way to make this useEffect logic unnecessary.

These two tests are the ones I was talking about in (the message of) my
earlier commit where state.resultRef was first introduced.

After further consideration, updating the two affected tests and
removing state.resultRef in favor of state.{result,previousData} makes
the most sense to me, since the queries/clients/variables reported in
the tests are no longer sometimes out of sync.

#9459 (comment)

#9459 (comment)

#9459 (comment)

#9459 (comment)

#9459 (comment)