Release 3.0 #5116
Merged
Release 3.0 #5116
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Netlify is failing after merging in Broken links
I'll get this fixed tomorrow. |
1 task
Sub-classing then re-exporting `Observable` leads to the `@types/zen-observable` types not being available, when `Observable` is exported from `@apollo/client`. This is because the `@types/zen-observable` class declaration (`declare class Observable<T>`) is replaced during TS compilation with the `class Observable extends LinkObservable` declaration, which doesn't expose any of original `Observable` methods. This means projects like Apollo Link that are using the re-exported `Observable` from `@apollo/client`, don't see any of the `Observable` methods when using Typescript. Instead of creating an `Observable` sub-class with the additional RxJS interop functionality, this commit uses TS global module augmentation to essentially add to the `@types/zen-observable` `Observable` type. It then adds the needed interop function to `Observable` directly. This allows external projects like Apollo Link to find all `@types/zen-observable` types, and keeps RxJS interop functionality in place. And just to add - method creation using `$$observable` was removed as `zen-observable` already does this: https://github.com/zenparsing/zen-observable/blob/f63849a8c60af5d514efc8e9d6138d8273c49ad6/src/Observable.js#L396
Make sure all parts of Apollo Client import `Observable` from a local module, instead of from `zen-observable` directly. This decoupling will make things easier as we investigate letting people use their own observables implementation.
Merge Apollo Link common + HTTP functionality into core
AC 2 exports `ApolloClient` as both the default and a named export. Since people will likely be using more exports from the `@apollo/client` package in AC 3 (e.g. integrated React hooks, Apollo Link's, etc.), let's kill the default export and only support the named export moving forward.
Remove the `ApolloClient` default export
With `preserveModules` off, rollup bundles the ESM code up and stores it in `dist/index.js`, when our first configured rollup job runs. This job is intended to run the `invariantPlugin` against all ESM code, updating `InvariantError`'s in place. It shouldn't be storing the results of running the `invariantPlugin` in `dist/index.js`. Enabling `preserveModules` ensures that changes are written back into originating files.
Ever since implementing support for custom merge functions, I have been unsatisfied with the MergeOverrides concept, especially because a mistake in the processing of overrides recently resulted in a fairly significant bug, fixed by commit 8c58be5. Instead of tracking MergeOverrides separately from the fields processed by processSelectionSet and processFieldValue (which is not only error-prone but also complicates the return values of those methods), we can embed the necessary FieldNode and __typename information within the field data returned by processSelectionSet, using recognizable FieldValueToBeMerged objects, which are safely removed by Policies#applyMerges before the fully processed fields are written into the EntityStore (which knows nothing about custom merge functions or FieldValueToBeMerged objects).
Although the needs of read functions are not exactly the same as those of merge functions, I have recently come to realize that the extra properties of ReadFunctionOptions as compared with the shared FieldFunctionOptions (readField, storage, and invalidate) actually do make sense for merge functions in some relatively obscure but nevertheless legitimate scenarios, and the prospect of using the same interface for both sets of options (that is, just FieldFunctionOptions) is appealing for all sorts of reasons: symmetry, simplicity, explainability, and even code sharing. Specifically, readField is useful for merge functions that maintain a paginated *set* of child objects (as opposed to a simple list), and need to read fields from those objects (which might be Reference objects) in order to deduplicate them. The storage and invalidate options are useful when a merge function is cooperating closely with a companion read function, and cannot simply communicate via the underlying cache data. For example, if options.storage is being used as a cache, the merge function might want to delete some cached data from it, to help the read function avoid reusing stale data. I'm not ruling out the possibility that these options interfaces will diverge again in the future. For example, I think the foreignObjOrRef argument passed to the options.readField function for merge functions should not be optional, as it is for read functions, but it seems acceptable to enforce that expectation with a runtime invariant, rather than using the type system. Also, it feels a little weird that the options.storage object can sometimes be null for merge functions, but I think my implementation comments adequately justify that choice. For now, I'd like to see how far we can get before this new-found symmetry becomes impractical again.
Unify FieldFunctionOptions between read and merge functions.
Fixes #5709 by reverting commit 83b5837. The removed test was invalid because a fragment with a type condition can never match an object without a __typename field in Apollo Client 3.0. The invariant was related to this test because the invariant failed earlier, effectively hiding the true misbehavior of the test.
Fixes #5733, which was caused by multiple watches having the same cache key, so none except the first were ever re-broadcast, since the first broadcast had the side effect of marking the later watches as clean, before this.watches.forEach had a chance to visit them. Background: PR #5644 reenabled an important optimization for the InMemoryCache#broadcastWatches method, allowing it to skip watches whose results have not changed. Unfortunately, while this optimization correctly determined whether the result had changed, it did not account for the possibility of multiple distinct consumers of the same result, which can happen (for example) when multiple components use the same query and variables via different useQuery calls. Fortunately, the fix is straightforward (if not exactly obvious): in order to assign distinct consumers different cache keys, it suffices to include the provided watch.callback function in the cache key. A more drastic way to fix #5733 would be to remove the caching of maybeBroadcastWatch entirely, which would not be a huge loss because the underlying cache.diff method is also cached. For now, though, with that backup option in mind, I'd like to preserve this optimization unless it causes any further problems.
#5748) The next major version of `graphql-js` deprecates the `introspectionQuery` constant (thanks to graphql/graphql-js#2124) that was previously leveraged in Apollo Client tests for obtaining the introspection query (to be clear, this is the query used to introspect a server, not the result of the introspection itself) in one particular test. This deprecation isn't entirely surprising since the `getIntrospectionQuery` utility method has existed since `[email protected]` and is the recommended way to obtain this query in more recent versions of `graphql`, so this changes that test to use that new method. I discovered this while investigating our compatibility with the most recently published `[email protected]` on `apollo-server`, `apollo-tooling` and `apollo-client`. Other than this, I didn't encounter any test failures when updating the root `graphql` dev-dependency to `[email protected]`! Deprecated by: graphql/graphql-js#2124 In Response to: graphql/graphql-js#2303 Relates to: apollographql/apollo-server#3649 Relates to: apollographql/apollo-tooling#1743
hwillson
approved these changes
Jan 7, 2020
|
Even though AC3 is still in beta, we're hoping to publish the first release candidate soon. In the meantime, we felt increasingly uncomfortable leaving |
|
@benjamn this appears to have lead to https://www.apollographql.com/docs/ now containing the v3 docs with no version dropdown to view other versions like it used to have. Is there a way to still access the 2.x documentation? |
|
Is there are any plans on publishing the migration guide with the most important changes were done since the latest version of previous major release v2.x? |
LevanArabuli
pushed a commit
to LevanArabuli/apollo-client
that referenced
this pull request
Nov 3, 2022
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR tracks changes that are slated to be released in the next major version of Apollo Client, based on the Apollo Client 3.0 roadmap.
PRs that introduce major or minor breaking changes should be merged into the
release-3.0branch instead ofmaster, so that we can keep releasing patch updates in the meantime. That doesn't mean everything here is a breaking change by any means—just that this branch is more experimental/unstable thanmaster.If there are minor breaking changes that we want to release before 3.0, we might also create a
release-2.7branch and pull request, similar to Release 2.5 and Release 2.6.Changes so far:
@apollo/react-hooks) into Apollo Client: Merge React Apollo hooks into Apollo Client #5357FragmentMatcherabstraction has been replaced with apossibleTypesoption for theInMemoryCacheconstructor: Remove FragmentMatcher abstraction from apollo-cache-inmemory. #5073freezeResultsoption, assuming always true: Remove freezeResults option, assuming always true. #5153InMemoryCachegarbage collection and eviction: Implement InMemoryCache garbage collection and eviction. #5310Stop returning unwanted__typenamefields in cache results: Stop returning unwanted __typename fields in cache results. #5311addTypenameToDocumentbeforeInMemoryCachereads/writes: Stop calling addTypenameToDocument before InMemoryCache reads/writes. #5320optimismto use lighter-weight dependency API inEntityCache: Update optimism to use lighter-weight dependency API in EntityCache. #5325ApolloClient#initQueryManagerQueryManager#startQueryObservableQuery#currentResultpreserveModulesoption, and consolidateutils/utilitiesdirectories: Reenable Rollup preserveModules option, and consolidate utils/utilities directories. #5437examples/bundling, with analysis tools: Apollo Client bundling examples and reporting #5449toReferencehelper function inFieldFunctionOptions: Provide toReference helper function in FieldFunctionOptions. #5506ObservableQuery#getCurrentResult: Avoid reading from cache in ObservableQuery#getCurrentResult. #5565InMemoryCacheresult caching: Finer-grained InMemoryCache result caching. #5617cache.identify(entity)for computing entity ID strings: Support cache.identify(entity) for computing entity ID strings. #5642previousResultinInMemoryCache: Stop paying attention to previousResult in InMemoryCache. #5644getFieldValueto read from foreignReferenceobjects: Allow getFieldValue to read from foreign Reference objects. #5651readfunctions: Storage and invalidation for custom field read functions. #5667mergefunction processing: Refactor custom field merge function processing. #5712FieldFunctionOptionsbetweenreadandmergefunctions: Unify FieldFunctionOptions between read and merge functions. #5722gqltag instead of internally in Apollo Client + apollo-link-http. Change link API to recievestringinstead ofDocumentNode