you will find that on the vast majority of projects, Redux is overkill
I've heard this statement 100 times and I have to object: it's not overkill, it's simply not the best tool for managing state in a React app for the reasons you mentioned and others as well (e.g. the extra effort/complexity/library for async operations, the extra setup for statically typed actions, etc.)
No matter if we're talking about 100 lines of code or 100,000.
On the other hand, an Apollo-based solution or a React Query one coupled with a BFF brings us closer to what should be our goal in the first place: an architecture that allows seamless state management between the server and the client.
Yeah my point is not that Redux is bad per se, more that the way we generally use it and other state management libraries is bad. If you have a lot of global state to manage that is truly frontend state, then it may be worth it to use Redux.
What I meant is that we're generally not using it correctly and it often leads to bad patterns where we end up shoving everything in a global store and recreating a cache from scratch.
Got it and I agree: it's not generally bad. It's not good either tho 😅 And has never been, regardless of project size.
we end up shoving everything in a global store and recreating a cache from scratch
👍🏽 I guess, independently of whether we use Redux or not, we'll end up creating some sort of cache-like system, because in the end, that's what out client side state is in a way: a cache for the backend state. So yeah, better if we don't start from scratch every time.
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.
I've heard this statement 100 times and I have to object: it's not overkill, it's simply not the best tool for managing state in a React app for the reasons you mentioned and others as well (e.g. the extra effort/complexity/library for async operations, the extra setup for statically typed actions, etc.)
No matter if we're talking about 100 lines of code or 100,000.
On the other hand, an Apollo-based solution or a React Query one coupled with a BFF brings us closer to what should be our goal in the first place: an architecture that allows seamless state management between the server and the client.
Yeah my point is not that Redux is bad per se, more that the way we generally use it and other state management libraries is bad. If you have a lot of global state to manage that is truly frontend state, then it may be worth it to use Redux.
What I meant is that we're generally not using it correctly and it often leads to bad patterns where we end up shoving everything in a global store and recreating a cache from scratch.
Got it and I agree: it's not generally bad. It's not good either tho 😅 And has never been, regardless of project size.
👍🏽 I guess, independently of whether we use Redux or not, we'll end up creating some sort of cache-like system, because in the end, that's what out client side state is in a way: a cache for the backend state. So yeah, better if we don't start from scratch every time.