Server state & UI state - a good concept as an alternative for using the Redux

Introduction 

As a modern Frontend Developer, you should have an eye for details, some architectural skills, and knowledge of how to design the application state. I will omit such skills as knowledge of CSS (style) or JS. For me, it’s a standard, so let’s focus on less obvious elements. 

How to design a good state? Have you ever thought about it? Should I use Redux? Why not base it on component states? How to handle the global state? This article will present some concepts about it. 

Redux - short description

While it’s mainly used as a state management tool with React, you can use it with any other JavaScript framework or library.

With Redux, the state of your application is kept in a store, and each component can access any form that it needs from this store. Redux's proposal is based on the global state. As a programmer, you can decide how to manage it and split it by context, etc.

But do we always need Redux? 

Redux toolkit 

RT (Redux toolkit) is a modern approach for people who love Redux in general. Let's follow the documentation: 

“Redux Toolkit contains packages and functions that we think are essential for building a Redux app. Redux Toolkit builds in our suggested best practices, simplifies most Redux tasks, prevents common mistakes, and makes it easier to write Redux applications.”

RT can reduce a lot of boilerplates which have to be written when you build the application based on Redux (reducers, actions, selectors, etc.). This approach is more accessible. The "slice" (A "slice" is a collection of Redux reducer logic and actions for a single feature in your app, typically defined together in a single file) is responsible for all. But we are still on the same “layer” - the global state.

A breath of fresh air - server state

Let’s go back to the question: Do we always need Redux? Why are many popular applications based on the global store? Do you remember your last project? Please, correct me if I’m wrong, but I suppose the JSONs were the majority of the application state (more than 70%) of your last app. Is it true? So why not separate the “server-state” and “UI-state” as well? Have you ever thought about it? If so, the React query is an ideal solution for you. 

React-query (TanStack Query) is powerful asynchronous state management for TS/JS, React, Solid, Vue, and Svelte. Based on react-query, you can Toss out that granular state management, manual re-fetching, and endless bowls of async-spaghetti code.

Why should we use the react-query? 

• Auto Caching;
• Dedicated Devtools;
• Auto Refetching - If a user leaves your application and returns to stale data, React Query automatically requests fresh data for you in the background;
• Parallel Queries - "Parallel" queries are queries that are executed in parallel, or at the same time, to maximize fetching concurrency;
• Offline Support - The caching strategy ensures that data is maintained even in offline mode;
• SSR Support - React Query supports two ways of prefetching data on the server and passing that to the queryClient;
• And some more.

Let’s think about your store again. My suggestion is to segregate all things that came out of the server as server-state (handled by react-query) and the same with the internal component state as UI-state (e.g. switch state, drop-down, etc. usually handled by useState). Then we have a more coherent and extendable division. Please, remember that whenever your applications need some kind of global state, you can still base it on the React Context provider or some lightweight libraries.

Summary

Most of the typical applications are still based on Redux. But the tendency is changing. A lot of front-end architects are still looking for better and better solutions. One could be a proposal to segregate the states into server-state and UI-state. But which tools you use is up to you. I strongly recommend checking the React-query (TanStack Query) option.

‍

Daniel