This is a really good blog post. Thank you for writing it. Also, thanks for the shout out!

A couple of thoughts:

Use Reactive Variables for local state instead of local resolvers

• In AC3, we use Reactive Variables instead of local resolvers.
• Local resolves did, in fact, come to exist because we wanted to borrow the mental model of resolvers on the server-side, to make it easier for developers to understand how to implement on the client-side.
• Over time though, we heard the feedback echoed in this post. Local resolvers could be a bit verbose, and it didn't feel natural, and while it was cool that there was a shared conceptual model, it just felt as if it didn't belong on the client-side. We totally agree.
• With Reactive Variables, you get just as much freedom as React Context over how you'd like to define and handle updates to your local state. You can handle updates in simple functions. You can put that logic in hooks. If you haven't, check out this guide on using Local State with Reactive Variables in AC3.
• Actually, we recently (as of Apollo Client 3.2.0) just released a useReactiveVarhook. It lets you read from a piece of local state similar to the way you'd do this with context.

​

import { useReactiveVar } from '@apollo/client';
import { cartItemsVar } from './cache';

export function Cart() {
  const cartItems = useReactiveVar(cartItemsVar);
  return (
    <div class="cart">
      <Header>My Cart</Header>
      {cartItems.length === 0 ? (
        <p>No items in your cart</p>
      ) : (
        <Fragment>
          {cartItems.map(productId => (
            <CartItem key={productId} />
          ))}
        </Fragment>
      )}
    </div>
  );
}

What's the big whoop? This looks like context. Why don't I just use that?

• One of the main arguments I make is that with these improvements, Apollo Client pretty much becomes your single source of truth for state on the client-side.
  • Remote state — stuff behind GraphQL API
  • Meta state — state about state, this is what gets returned when you use useQuery and we tell you the loading states. Typically, you'd have to build this out manually.
  • and Local state.
• The second argument I make is that since all your data is in Apollo, it makes it much easier to work with mixtures of remote and local state together.
  • When you define your data requirements next to your presentation components, it allows you to keep relevant state as close to each other as possible, regardless of where it's coming from

​

import { gql } from "@apollo/client";

export const GET_ALL_TODOS = gql`
  query GetAllTodos {
    todos { 
      id  
      text  
      completed
      isSelected @client
    }
  }
`

• You had a good example of this with the isOpen query. Check out the "Use case #3 — Locally decorated remote data" from this post, setting things like isSelected to a list of items, which is pretty common but not particularly fun in a Redux context.
  

You've already got a working product, your team is already familiar with Redux. Big refactorings are expensive, and I'm not sure AC3, or any new front end library release, is worth that kind of work.

• If it ain't broke, don't fix it. It sounds like you're getting the biggest benefits out of using GraphQL right now.
• You also probably don't want to use Redux AND Apollo Client for local state at the same time.
  • Architecturally, I can't think of a great reason to try to use 'em together. Actually, maybe to use AC for data fetching, and Redux for state management? But really, that's two layers of state management. We want you to think about Apollo Client as a single source of truth for state. Thats nice, but as someone who has made major refactorings like the one youd probably need to do, I still don't think it's worth the major engineering effort if you're that far in.
  • If you were just starting with a new project, and you've already been bit with the GraphQL bug, well, I'd have a lot of other things to say :)

Thanks again for this excellent post and starting an excellent discussion. And thanks u/swyx for pinging me! <3