https://s3-us-west-2.amazonaws.com/secure.notion-static.com/45780597-9a3a-4ca2-bef0-bedfde5520e2/23_(1).png

In Apollo Client & Client-side Architecture Basics, we learned that most client-side apps work with a couple different types of state.

When we talk about local state management, we're really referring to the pattern of attaching properties and objects that only exist on the client-side. That's shared (global) state.

shared (global) state is state that we sometimes don't want to lose when the routes change. It's also state we want to enable reactivity for.

shared (global) state can be combined with remote data from backend services, or we can use it to build a truly local state-only app.

The ultimate goal of shared (global) state is to enable view-layer components to subscribe to pieces of it, get notified when it changes, and re-render.

In Apollo Client 3, using Cache Policies and Reactive Variables, you can elegantly configure the cache to add pieces of local state. In Apollo Client 2x, we used local resolvers to accomplish this, but we prefer the newer approach for its cleanliness and lack of verbosity.

In this article, we'll learn about how to get started with local state management using Cache Policies and Reactive Variables.

We've also documented use cases that you'll likely encounter when working with a mixture of local state and remote data. To wrap up this guide, we'll demonstrate how to use the new cache APIs for each use case.

<aside> 💡 Howdy! 🤠 Just looking for the code? Visit @apollographql/ac3-state-management-examples on GitHub to see best practice examples of local and remote state management using the new Apollo Client 3 cache APIs.

</aside>

Cache policies

Cache policies are a way to customize reads and writes to the cache.