-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Apollo Client 2.0 [Beta] #1941
Apollo Client 2.0 [Beta] #1941
Conversation
@jbaxleyiii, thanks for your PR! By analyzing the history of the files in this pull request, we identified @kamilkisiela, @stubailo and @michalkvasnicak to be potential reviewers. |
Generated by 🚫 dangerJS |
87566ec
to
4cbea46
Compare
The first alpha is ready for release! InstallationThe 2.0 of apollo is split into a few packages. To try it out in your app you can install the following npm i --save apollo-client@alpha apollo-cache-inmemory@alpha apollo-link This will give you the replacement for networkInterfaces (links), the current apollo-cache (cache-inmemory) and the new client. For updating your app, you should only need to change the constructor. For example, a meteor SSR app that looked like this: import { render } from 'react-dom';
import { onPageLoad } from 'meteor/server-render';
// apollo imports
import ApolloClient, { createNetworkInterface } from 'apollo-client';
import { ApolloProvider } from 'react-apollo';
import { App } from '/imports/app';
export const start = () => {
const client = new ApolloClient({
networkInterface: createNetworkInterface({ uri: 'http://localhost:3000' }),
initialState: { apollo: window.__APOLLO_STATE__ },
});
const WrappedApp = (
<ApolloProvider client={client}>
<App />
</ApolloProvider>
);
render(WrappedApp, document.getElementById('app'));
};
onPageLoad(start); Now looks like this: import { render } from 'react-dom';
import { onPageLoad } from 'meteor/server-render';
// apollo imports
import ApolloClient from 'apollo-client';
import Link from 'apollo-link-http';
import Cache from 'apollo-cache-inmemory'
import { ApolloProvider } from 'react-apollo';
import { App } from '/imports/app';
export const start = () => {
const client = new ApolloClient({
link: new Link({ uri: 'http://localhost:3000' }),
cache: new Cache(window.__APOLLO_STATE__),
});
// XXX this will have to be updated in react-apollo
client.initStore = () => {}
const WrappedApp = (
<ApolloProvider client={client}>
<App />
</ApolloProvider>
);
render(WrappedApp, document.getElementById('app'));
};
onPageLoad(start); The upgrade path revolves around replacing networkInterface with a link and initial state with a cache. Known issuesCurrently returning multiple results from links are not supported. Subscriptions should work, as should batching, all other link functionality. React apollo has not been heavily tested against this release yet. Right off the bat, you will need to add client.initStore = () => {} after you create your client because Happy testing! |
Fort those interested in what an upgrade will look like so far: https://github.com/jbaxleyiii/ReactNYC-SSR/pull/1/files?diff=split#diff-096103d8490b885f9d5037baea6aea80 |
@jbaxleyiii thanks for all the work here! Sorry for hijacking this thread, but I feel that 2.0 would be the opportunity to get rid of the global fetch polyfill: Have you had the chance to further discuss whether removing the polyfill from the default packages is an option for 2.0? See apollographql/apollo-fetch#30 |
@jbaxleyiii Could you provide more info about this:
|
@ctavan I have seen it and I do agree! Fetch is removed from all core AC code and I will work to remove it from fetcher as well. @tnrich one of the super cool things about the 2.0 is support for things like using the |
Another question for the rising star of version 2.0: could it be possible to switch the link on a per query-basis? Use-cases could be f.e. to have a default-link via WS and use another HTTP-Link for uploading and/or auth-handling via cookie... With the new interfaces it could be possible, judging by a quick look - or am I on a completly wrong path here? |
@benbender you should be able to build any logic with apollo-link split just like http+ws for subscription example |
Really looking forward to @jbaxleyiii what kind of server support will be required for |
hey @furuholm, just npm install & start and you can test it over graphiql 🎉 |
Codecov Report
@@ Coverage Diff @@
## master #1941 +/- ##
=========================================
Coverage ? 83.99%
=========================================
Files ? 35
Lines ? 1949
Branches ? 458
=========================================
Hits ? 1637
Misses ? 306
Partials ? 6
Continue to review full report at Codecov.
|
81942a8
to
780534d
Compare
@jbaxleyiii I'm playing with |
@s-panferov it shouldn't be gone, but we might have forgotten to expose it as a public API. Thanks for the feedback! |
Looks like James added it here: dbe1639 |
@s-panferov I will publish an alpha today with it back in there! I'll comment when its out and how to use it! |
@@ -190,7 +190,14 @@ export function writeSelectionSetToStore({ | |||
context, | |||
}); | |||
} else { | |||
if (context.fragmentMatcherFunction) { | |||
// if this is a defered field we don't need to throw / wanr |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
some typos in this comment: warn/wanr; also deferred has two rs
tldr;
The 2.0 version of Apollo is targeting a more customizable experience with GraphQL. It prioritizes features like custom execution chains (using Apollo Link) and custom stores while providing powerful defaults. It will be an overall minor change to the API so you won't have to change very much code in your current app at all! Apollo ❤️ backwards compat
About
The 2.* version of Apollo Client builds on the original principles of the project. For reference, those goals are:
Based on feedback from a wide variety of users, the 2.* version will double down on being incrementally adoptable and flexible by allowing much stronger extension points. Customization of the client (i.e. data store, execution chain, etc) will be first class in the revised API. The next version will also take steps to reduce the overall size of the default client and provide the foundations for Apollo powering more of the application experience from development to production (i.e. client side state management).
The goal of the 2.0 launch is not to provide all of the new features that have been asked to be built in. Instead, the 2.0 launch makes a few key changes to both management of the code base (lerna / small modules) and the changes necessary to support custom stores and links fully. Apollo Client 2.0 is the jumping off point for user-land driven innovation (custom stores, custom links) and internal refactor (moving query manager into links, breaking apart the store / links into packages, etc)
Details
There are three main tasks for the 2.0 version.
Immediate wins
Contributing
If you are interested in contributing to the 2.0 release that is SO great!! There are a number of ways to help out! Please comment on this PR if you want to do any of the following!
Installation instructions
The 2.0 of apollo is split into a few packages. To try it out in your app you can install the following
This will give you the replacement for networkInterfaces (links), the current apollo-cache (cache-inmemory) and the new client.
For updating your app, you should only need to change the constructor. For example, a meteor SSR app that looked like this:
Now looks like this:
The upgrade path revolves around replacing networkInterface with a link and initial state with a cache.
Happy testing!