Merge React Apollo hooks into Apollo Client #5357
Merged
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
Falling back on the Jest default will work now that we're not using a monorepo, and open things up to test further nested `__tests__` directories (which will be needed to test React changes).
React Apollo uses its own copy of `OperationVariables`; let's update AC's version, so we can configure RA to use it after it has been merged in.
This commit kicks of the initial merge of React Apollo into Apollo Client. It merges in the source of: - @apollo/react-common - @apollo/react-hooks - @apollo/react-testing The HOC (@apollo/react-hoc) and components (@apollo/react-components) packages are not going to be brought into Apollo Client, and the React SSR package (@apollo/react-ssr) will also be kept separate for now. This commit represents the initial merge of the code (with changes required to get all tests passing), but does not represent the final state of Apollo Client's React integration. Now that the RA code is part of AC, work on leveraging the tighter RA/AC integration can proceed.
The TS rules are a bit more strict in this project (compared to React Apollo).
New exemptions required by React Apollo
This is just a preliminary bump; this number will go down as we start refactoring.
This, along with using `@testing-library/react`'s `wait` function, gets rid of all React "you must use act()" warnings.
These new rollup config elements will create a separate
`testing.js` CJS based bundle, that contains React testing
utilities like `MockedProvider`. Applications can access this
new bundle like:
import { MockedProvider } from '@apollo/client/lib/testing';
Apollo Client is already pulling a similar type from Apollo Link, so this updates the React code to do the same.
This reverts commit 6ebacef.
Apollo Client use doesn't really benefit from having a UMD bundle, since the project has external dependencies that aren't bundled into the UMD.
These changes wire up a new Rollup based bundling approach. We no longer build and provide an ESM bundle. By providing an ESM bundle, and pointing to it via the `package.json` `module` property, we were inadvertently reducing the effectiveness of build tool tree shaking / dead code elimination capabilities. For example, since webpack was getting the ESM bundle from the `module` property, it wasn't able to get to the fully extracted ESM source in `./lib`, to use it for DCE. With the changes in this commit, the `package.json` continues to point `main` to the CJS bundle (with all Apollo Client code in it), and now points `module` to the non-bundled ESM entry point of `./lib/index.js`. This means we're leaving the bundling of ESM code up to Apollo Client consumers and their build tooling, most of which will be able to leverage the expanded ESM source to build more efficient bundles on their side. We'll re-visit this strategy as work on AC 3 progresses, but so far the results have been promising.
@benjamn updating to 0.11.2 introduced: ``` src/cache/inmemory/entityCache.ts:2:15 - error TS2305: Module '"apollo-client/node_modules/optimism/lib"' has no exported member 'OptimisticDependencyFunction'. ```
The source links needed to be updated to match the new non-monorepo project structure. I'm not sure why the API is being excluded from link checking, but it's defintiely needed. Links like `/api/core/#ApolloClient.resetStore` aren't working, when they should be. But since the API was being excluded previosuly, this commit fixes the config to exclude it again.
This reverts commit 68195a9. benjamn/optimism#52
On the React Apollo side, it's only required when using `@apollo/react-ssr`. Since we're not merging in the RA SSR code yet, we don't need it as a peer dep.
`wait` already returns a promise so we can just return it.
Since we're publishing from within the "dist" directory, and publishing is going to be blocked from the project root, we don't need to maintain an .npmignore file.
These changes include a new script that is used to prepare the "dist" directory for publishing. This includes: - Copying a modified package.json into "dist", after it has been adjusted (remove "./dist" directory prefixes, remove un-needed package.json properties, and remove the private flag). - Copying the README.md into "dist". This script is now called as part of the "predeploy" script. The "deploy" script will now also cd into "dist" before publishing, so only the contents in "dist" will be published to npm (and "dist" will essentially serve as the published package root).
abernix
reviewed
Sep 24, 2019
|
We might change the approach introduced in 4c7af4e, but I'll merge this PR as is, and we'll continue the discussion / changes separately. |
|
@hwillson I'm surprised that no one has asked this yet, but how will this change affect those of us who use Apollo without using React (in my case, Angular)?
Addressing non-react usage (if still supported in some way) would be helpful. Edit: For reference, I found my way here from the changelog Edit 2: Oops! I jumpted the gun. Sorry! Farther down I see that there is a separate entry point for non-react usage
|
|
@thefliik If you don't want to use React or AC's React integration, you can import from import { ApolloClient } from '@apollo/client/core';Using This will definitely be better documented when we go live with AC 3. |
|
@hwillson makes sense. Thanks for the info! |
2 tasks
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 extracts and merges the React Apollo hooks code into the Apollo Client core, which means this is now possible:
When Apollo Client 3.0 launches, library users will no longer have to install separate packages to use React hooks with Apollo Client. Everything needed to combine Apollo Client with React to manage GraphQL based data will be available through one package,
@apollo/client. Aside from making things easier for library consumers, these changes also set a future foundation for tighter integration between Apollo Client and its React integration. More involved changes that previously required updates toapollo-clientandreact-apolloseparately can now be managed in one central location, which will help reduce bugs and speed up feature request additions that involve both projects.Important notes about these changes are listed below.
1. React Apollo HOC/Component deprecation
We're following the React team's lead and are planning for a hooks only future. To this end, this PR only merges React Apollo's hooks into the AC core. RA's HOC and render proper components are not being moved over, and will continue to be housed under the
@apollo/react-hocand@apollo/react-componentspackages. Those paradigms will be updated behind the scenes to use the hooks from Apollo Client, but they will be maintained separately. When Apollo Client launches, React Apollo's HOC/Components will be officially deprecated (but will continue to receive bug fixes and other forms of support until sometime in 2020).2. New bundling strategy
To help offset the increased bundle size these changes introduce, this PR includes a new bundling strategy to help modern build tooling better leverage tree-shaking / dead code elimination.
The current version of Apollo Client leverages a default CJS bundle (pointed to by the
package.jsonmainproperty), and an ESM bundle (pointed to by thepackage.jsonmoduleproperty). While AC breaks all original ESM source out into./liband makes sure its accessible in the final package, the fact that the ESM bundle is being pointed to bymodulemeans that the original ESM code can't be leveraged properly for tree-shaking / DCE. Tools like webpack are only seeing the combined ESM bundle, which means it can't traverse the original code and more effectively remove unreachable elements.This PR retains the
package.jsonmainCJS bundle approach (since having all code available on the server isn't as big of a deal), but no longer builds an ESM bundle. Thepackage.jsonmoduleproperty now points to./lib/index.js, and we're relying on modern build tooling to tree-shake / DCE / bundle the AC source.This PR also removes UMD bundle support. UMD use of this project has been quite low, and has never really been that effective due to the external dependencies Apollo Client requires.
3. React Apollo SSR stays separate (for now)
React Apollo's SSR package (
@apollo/react-ssr) isn't being merged into Apollo Client, yet. For now anyone interested in using SSR with Apollo Client should still install the@apollo/react-ssrpackage directly. When React's suspense + data fetching approach finalizes (hopefully in the next couple of months), we'll be taking a closer look at AC's SSR approach as we work on our suspense integration.4. React testing
This PR merges React Apollo's
@apollo/react-testingcode into the Apollo Client core, but it is not included by default in application bundles (since it's really only needed during development). To access React testing utilities from AC, direct cherry-pick imports can be used:This might change, but for now this is the approach outlined in this PR.