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.
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?
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.
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?
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.
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.