- Apollo Client is now distributed as the
@apollo/clientpackage (previous versions are distributed as
@apollo/clientpackage includes both core logic and GraphQL request handling, which previously required installing separate packages.
- ‼️ The
@apollo/clientincludes React-specific code so it's very important to use
- Apollo's cache (
InMemoryCache) is more flexible and performant. It now supports garbage collection, storage of both normalized and non-normalized data, and the customization of cached data with new
- No more
apollo-angularincludes now GraphQL request handling (
apollo-angular/http), which previously required installing separate packages.
- New Apollo Angular no longer supports the
Update with Angular Schematics
Apollo Angular comes with set of migration schematics:
Important! Migration doesn't cover all use-cases and NgModules like
HttpLinkModulehave to be deleted manually. To improve the migration script, please open issues and PRs!
To get started with the v2.0, you will change your imports to use the two packages. A typical upgrade looks like this:
A simple usage of Apollo Angular upgrading to the 2.0 would look like this:
apollo-angular-link-http-batchare now available under
apollo-cache-inmemoryare now under
@apollo/clientbecause the latter includes React-related code.
This is the most important part of migrating to 2.0.
Few things to be explained.
SelectPipe allowed us to completely remove the need for
NgModule). There are two reasons. We haven't seen any big applications using the pipe and the logic there is very simple to recreate.
Because we removed the
SelectPipe, there was no need to keep the
Apollo class is now defined as a tree-shakable injectable and provided to the root injector. You can use it from anywhere in the application.
HttpLink and HttpBatchLink
The previous version of Apollo Angular (v1.0) setup had two extra packages:
Now it's just one:
apollo-link-* packages, that were previously maintained in the https://github.com/apollographql/apollo-link repo, have been merged into the Apollo Client project. These links now have their own nested
@apollo/client/link/* entry points. Imports should be updated as follows:
apollo-angular package includes
graphql-tag as a dependency and re-exports
gql. To simplify your dependencies, we recommend importing
apollo-angular and removing all
Using apollo-utilities without the rest of Apollo Client
apollo-utilities package has been removed, but you can access the utilities themselves from the
@apollo/client/utilities entry point:
Using apollo-cache and/or apollo-cache-inmemory without the rest of Apollo Client
apollo-cache-inmemory packages have been removed, but if you're interested in using Apollo Client's cache by itself, you can access their contents with the
@apollo/client/cache entry point:
Breaking cache changes
The following cache changes are not backward compatible. Take them into consideration before you upgrade to Apollo Client 3.0.
- By default, the
InMemoryCacheno longer merges the fields of two objects unless those objects have the same unique identifier and that identifier is present in both objects. Additionally, the values of fields with the same name are no longer merged recursively by default. You can define a custom
mergefunction for a field to handle both of these changes for a particular field. You can read more about these changes in Merging non-normalized objects. (PR #5603).
- All cache results are now frozen/immutable, as promised in the Apollo Client 2.6 blog post (PR #5153).
IntrospectionFragmentMatcherhave all been removed. We recommend using the
possibleTypesoption instead. For more information, see Defining possibleTypes manually (PR #5073).
- The internal representation of normalized data in the cache has changed. If you’re using
apollo-cache-inmemory's public API, then these changes shouldn't impact you. If you are manipulating cached data directly instead, review PR #5146 for details.
(client/cache).writeDatahave been fully removed.
cache.modifycan be used to update the cache.
For more details around why writeData has been removed, see PR #5923.