About ten months ago, I wrote an article about handling asynchronous requests in ReactJS.
That's a lot of boilerplate code (API functions, asynchronous actions, Thunk functions, reducers and the state selectors) just to render some asynchronous data, don't you think?
I accepted that asynchronous data doesn't belong to state and searched for other solutions.
The past month I'm experimenting with swr. I'm amazed on how much less effort is required for the same result. Even the UI feels better, faster and more responsive.
swr caches the data, then it provides the stale data first and re-validates to update the stale data if necessary.
Here's a demo I prepared.
I have included a one second delay for each request for you to notice that once a page is fetched, when you re-visit it you won't wait for that second because swr will first retrieve that page's data (stale) from the cache.
Asynchronous data was my biggest part of Redux state, and once that's been replaced, there's little shareable UI state. That can easily be replaced with React's Context API or I could use the promising Recoil.
It's good to know Redux but it's better to know when to replace it.
Top comments (1)
Couldn't agree more 👍
In our team we also started to remove/refactor Redux, that will only stay for some minor data sharing across the whole app (couple of selectors/dispatchers).
Would just add, don't put async stuff and business logic into redux, create hooks instead, and put business logic close to component that is responsible for it (not the whole app needs to know about it).
SWR is an awesome library 🚀