Part 1: Local State Management

May 10, 2021

The post is part of a presentation I gave at my employer, MOIA, as part of our "Continuous Learning" sessions and as the title suggests, it's about managing local state in the front-end, with a comparison of Redux and Apollo Client, and how we can carry out sate management using Apollo Client.

The "Why?"

When we talk about Local State Management we refer to a pattern of attaching primitive and non-primitive properties that are only accessible on the client. The goal of this is to enable our components (the view layer) to subscribe to a part of the store, get notified when that part changes, and at the end, to re-render.

There are many open source state management libraries with decent comminity around them that are well mentained. Five years ago, the go-to solution was Redux. Today, there are others, but we will focus on Apollo Client in this post.

What is common for these librareis is that the data we store in them is actually global. So, here comes the question - What is global state and what are the benefetis?

Global State

As the name suggest, this is just an object that is globally accessible and can be update from anywhere within the client app. There are some benefits that are worth mentioning:

•     • We avoid prop drilling (solves problems like re-rendering, re-usability, testability)
•     • The data can be accessed without copying or duplicating
•     • Communication with isolated components and hooks
•     • You can always save and predict the app's state easily because it is supposed to be a single source of truth

It is worth mentioning that the terminology “Global state” is not that great because the general interpretation of “Global state” in most user-oriented apps is “a storage for all data your app is detailing with”.

Types Of State

As you would guess by the title of the section - there are several types of state, but for the sake of simplicity, let us divide them into client and server states.

Main differences between client and server states:

•     1. Where they are stored
•     2. Speed of access
•     3. How they are accessed
•     4. Who can make changes to them

Client state is:

•     1. Temporary and not persisted between session
•     2. Accessed synchronously (this means that usually there is no latency at all)
•     3. Local - used by a single client
•     4. Up-to-date

Server state is:

•     1. Remotely stored
•     2. Asynchronous
•     3. Used by multiple clients
•     4. Might be out-of-date

With this in mind we have a good picture about the types of states.

Now comes the definition of declarative and imperative paradigm and I am sure most of you know it, but as it is the key difference between the Apollo Client and Redux, I would like to point it out.

In simple terms, declarative - it should look like this and imperative - this is what you should do.

Problem with Redux

•     1. It encourages us to treat all states the same (we store all data in one place and it is hard to distinguish between)
•     2. It comes with additional middlewares for managing side-effects (async data)
•     3. Almost all of the operations are imperative

Then we have the Apollo Client which is not the way Redux is!

Apollo Client state management

•     1. Client and server data can be clearly distinguished (@client directive)
•     2. Client and server state is cached and retrieved using the same declarative mechanism

In Part 2: State Management in Apollo Client, we will look deeper into how we can use Apollo Client for state management.