Implement reactive variables for tracking local state.

[benjamn]

Reactive local variables are functions that allow you to store local state in a well-known, private location, outside of the cache, consume that state while reading queries from the cache, and update the state whenever you like.

Basic usage:

const lv = cache.makeLocalVar(123)
console.log(lv()) // 123
console.log(lv(lv() + 1)) // 124
console.log(lv()) // 124
lv("asdf") // TS type error

TypeScript infers the value type of the variable based on the initial value, which is why switching from a number to a string is a type error here.

Any parts of any queries that relied upon the value of the variable will be invalidated when/if the variable's value is updated:

const cache: InMemoryCache = new InMemoryCache({
  typePolicies: {
    Person: {
      fields: {
        name() {
          return nameVar();
        },
      },
    },
  },
});

const nameVar = cache.makeLocalVar("Ben");

const query = gql`
  query {
    onCall {
      name @client
    }
  }
`;

cache.writeQuery({
  query,
  data: {
    onCall: {
      __typename: "Person",
    },
  },
});

expect(cache.readQuery({ query })).toEqual({
  onCall: {
    __typename: "Person",
    name: "Ben",
  },
});

nameVar("Hugh");

expect(cache.readQuery({ query })).toEqual({
  onCall: {
    __typename: "Person",
    name: "Hugh",
  },
});

With this new primitive available, it should not be necessary to construct awkward queries just to read and write local state, since you can read the variable directly with nameVar() and update its value by calling nameVar(newValue).

[benjamn]

I'm pretty proud of how short this implementation can be, thanks to our existing dependency tracking machinery.

[hwillson]

Yay optimism!! Thanks for working on this @benjamn - looks great!

[d-asensio]

Thanks @benjamn! this really makes the difference!

I made a simple choice list example in a code sandbox to test that feature and it looks amazing:

Before reactive variables (using two different approaches to achieve the desired behavior):
https://codesandbox.io/s/apolloclient-3-local-state-management-before-reactive-variables-lngfo

After reactive variables:
https://codesandbox.io/s/apolloclient-3-local-state-management-with-reactive-variables-w2uxk

I will seriously considerate to switch from redux to apollo ;)

[rektide]

As an old-hand users & fan of the Flyd "minimalistic but powerful, modular, functional reactive programming library", I feel very at home & used to this! Flyd has a similar api, where myVar() returns the variable and myVar(42) updates the value of it. It was neat seeing this api pattern again! Thought I'd drop by & mention the similarity. Cheers, thanks for the hard work all.

[benjamn]

Just a quick note that we've made this API even easier to use (makeVar is just a free-floating function now): #6512