Feature: Opt-in to including Apollo Client local resolver code in your bundle

[hwillson]

While the local resolvers API has been superseded by the type and field policies API, we think it will be too jarring to remove local resolvers completely from Apollo Client 4. If people aren't using local resolvers however, we would like to ensure that the local resolver code in core can be tree-shaken away. To do this, we're going to make local resolvers opt-in along these lines:

...
const client = new ApolloClient({ 
  localState: new LocalState({
    resolvers: {...}
  }),
  cache: new InMemoryCache,
});
...

All local resolver code in core is currently isolated to the LocalState class. If interested in using local resolvers, Apollo Client will require creating a LocalState instance, and passing it into the ApolloClient constructor (and we'll consider changing LocalState to something like LocalResolvers, to reduce confusion).

[benjamn]

I think I've changed my mind about this!

If we're already asking folks to change how they pass local resolvers to the ApolloClient constructor, I think we should take this opportunity (AC4) to release local resolvers back into the link chain, which involves the following steps:

1. Sending queries into the link chain with @client directives still intact
2. Stripping those @client fields in HttpLink and other terminal links, if not handled earlier
3. Providing an @apollo/client/link/local-resolvers package that moves the current LocalState implementation into an easy-to-switch-to ApolloLink, prioritizing backwards compatibility (and equivalent bundle sizes) as much as possible
4. Providing another link that wraps the graphql package's execute pipeline, like @apollo/client/link/schema currently does, which may indicate an opportunity to reuse @apollo/client/link/schema, though that package pulls in the validate code as well, so we might want a version without that code (TBD)

I want to thank @vigie for pointing out in #7072 that it's not fair/reasonable of us to deprecate local resolvers AND keep standing in the way of implementing them in the link chain (like apollo-link-state did) by stripping out @client directives before passing queries into the link chain.

Since the link chain is async-friendly, it's tempting to save bundle size by using dynamic import() to fetch parts of the graphql package, though that may not be helpful for code that's always needed during page load.

[vigie]

If this is the decision (and I would fully support it), suggest this is closed in favor of a new issue to track the work involved in creating @apollo/client/link/local-resolvers?

[fbartho]

It's been a year, but but I feel like this still needs an update!

What's the recommended way of doing local-logic?

https://www.apollographql.com/docs/react/local-state/local-resolvers/ points at this thread in its deprecation warning

[jpvajda]

Closing in favor of #10060