State management in a web app can be a real PITA and confusing topic to tackle down.
The way that you handle the state is something you should take care of from the very beginning.

Starting for: what is state and what type of state do I have?
The application state can be split into at least two types :

🕙 Server state: asynchronous and doesn't really belongs to the app, remotely persisted, potentially out-of-date.

📺 UI state: synchronous, easily accessible, derived from user interaction. Complete ownership
Since the nature of the state is different in each case we should choose the correct tool and "architecture" to manage it.

There is a ton of solutions out there and I think that all of them are good one when used correctly.

Like Redux, RTK, zustand, Mobx, etc
But in the past, there was a tendency to maybe overuse some tools forcing them to work for every possible case bending the solution to manage the different natures of the state.
We were all there at some point when we had all the state inside one huge Redux global state.
But we can do better!.
React is a state management solution by itself!
I'm not the only one how said so

https://kentcdodds.com/blog/application-state-management-with-react ( @kentcdodds )

And this tool is meant to manage your UI state by using different techniques as prop-drilling, local state, and Context.
By differentiating the UI state vs Server state and using React itself to manage the UI state we solve one piece of the puzzle. What we can do for the rest?

The server state is a different beast to tame.
When dealing with async and remote data you have multiple "inner state"
Since you are requesting data from an external source the request can be at least in the following states: idle, loading, failed, or succeed
An for sure you can manage that different states with just React hooks as you can see here https://github.com/matiasfha/react-query-example/blob/base/src/hooks/useFetchState.js
And that works!, but there is a ton of other cases that are not handled by that, like What happens if you need to fetch the same data? This solution can cache so will request it again.

Can you do optimistic updates? Yeah, you can but you need to craft that by yourself.
We know that Naming and Caching are the two bigger problems in Computer Science right?
http://martinfowler.com/bliki/TwoHardThings.html

So, in this case, we should choose a 3rd party library, and as I said before there is a ton of possibilities. For this case, the main options are React Query and SWR
I choose React Query by @tannerlinsley
What is RQ? is a Cache Layer for your app.
It doesn't care from where the data come, the important part is that works with any Promise based request!
The principle of the RQ architecture is the encapsulation of business logic by extracting the data fetching ceremony to custom hooks.

@kyleshevlin have something to say about encapsulation and React hooks https://kyleshevlin.com/use-encapsulation
How react-query works?
In a nutshell, you have two hooks `useQuery` and `useMutation` that do the heavy lifting for you. Those hooks will take care of managing the fetch and the promises states and will return a few booleans that let you know what happens.
Don't worry about the booleans there, is a state machine under the hood.
Also, since react-query works as a cache your data will live under a query key that you can build by passing a string or an array to the hooks.
And if you liked this thread, please share the first tweet, and follow me for more content about React, web dev, and dev soft skills. https://twitter.com/matiasfha/status/1390392194511642629?s=20
You can follow @matiasfha.
Tip: mention @twtextapp on a Twitter thread with the keyword “unroll” to get a link to it.

Latest Threads Unrolled: