Redux has nothing to do with managing backend state and if you're using it just to have global "copy" of the backend on your frontend or "caching", of course it will be just unnecessary overhead.
As well as it's not really related to the API calls in the first place. It shouldn't be compared to react-query or apollo.
Redux is architectural pattern, easier debugging and powerful middlewares like redux-saga for managing complex, really complex workflows and states.
If you use it just for data fetching, global variables or prop drilling issues, you are using wrong tool.
That's exactly my point. Once you get rid of using it for backend state, it's hardly needed for most simple applications. And I'm picking on Redux but any state management library falls into some of the same temptations. Yet everyone likes to start a project with Redux (or MobX, etc.) because it's so commonly used and referenced before they even have any real use case for it.
In the Redux docs, it has plenty of examples of using it for storing backend state (redux.js.org/recipes/structuring-r...), so I disagree with you that that was never the intention, not to mention all the libraries that have sprung up (mentioned in the article above, such as redux-saga) to deal with backend state. If it was never the intention, I would expect Redux docs to warn against this very tempting use case instead of showing you how to do it. From experience, I would say there are plenty of people using it for this reason, maybe even the majority.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Redux has nothing to do with managing backend state and if you're using it just to have global "copy" of the backend on your frontend or "caching", of course it will be just unnecessary overhead.
As well as it's not really related to the API calls in the first place. It shouldn't be compared to react-query or apollo.
Redux is architectural pattern, easier debugging and powerful middlewares like redux-saga for managing complex, really complex workflows and states.
If you use it just for data fetching, global variables or prop drilling issues, you are using wrong tool.
That's exactly my point. Once you get rid of using it for backend state, it's hardly needed for most simple applications. And I'm picking on Redux but any state management library falls into some of the same temptations. Yet everyone likes to start a project with Redux (or MobX, etc.) because it's so commonly used and referenced before they even have any real use case for it.
In the Redux docs, it has plenty of examples of using it for storing backend state (redux.js.org/recipes/structuring-r...), so I disagree with you that that was never the intention, not to mention all the libraries that have sprung up (mentioned in the article above, such as redux-saga) to deal with backend state. If it was never the intention, I would expect Redux docs to warn against this very tempting use case instead of showing you how to do it. From experience, I would say there are plenty of people using it for this reason, maybe even the majority.