I did also, many coming from classic programming that hasn't touched upon functional ways of thinking usually struggle since they're prone to shortcuts whereas React really likes you to keep everything as transformations (or as some would call it functional style).
Much React work these days is confined into components, people sadly over-do it also because they perceived Redux as overkill and try to shoehorn entire applications into core React hooks (that are mostly designed for smaller components or at most views).
This is needless when Redux (with Redux-toolkit) has recipies that solves the whole-app dataflow problems well (people have issues with Redux because their components got overly complex in the past by shoehorning component issues into Redux instead and now they're complicating things in the other direction).
First rule of not messing up React/Redux: Don't mutate data, 90% of messups I see with fresh people is breaking this. Everything should become transforms! To accomplish this the spread operator (...) in JS/TS along with map/reduce/filter are your biggest friends. (You can do optimizations but 98% of the time you won't work on big enough datasets that you need to do that)
Thus when you do setX (of state hooks) you set your transformed data, same with sending messages in Redux, your Redux reducer acts upon a message to transform the internal state.
Transforming mutations into react-compatible object creation is not always trivial, particularly with twisty object graphs. I once spent a week trying to untangle a reducer monstrosity that wished it could mutate. In the end, I don't think I totally fixed it. It can be hard.
Joking aside, you're right, often it's almost easier in recursive cases to just go with flat object lists and keeping identities on objects and keep parent id's around.
In my view, React is a theoretically beautiful piece of software, and if you're planning on building a synchronized networked system keeping in line with what makes it beautiful will give you it almost for free.
For many practical cases (especially smaller SPA's/pages) however it's probably better to just go with Vue or similar and mutate away and let the system handle all update checks for you instead.
Much React work these days is confined into components, people sadly over-do it also because they perceived Redux as overkill and try to shoehorn entire applications into core React hooks (that are mostly designed for smaller components or at most views).
This is needless when Redux (with Redux-toolkit) has recipies that solves the whole-app dataflow problems well (people have issues with Redux because their components got overly complex in the past by shoehorning component issues into Redux instead and now they're complicating things in the other direction).
First rule of not messing up React/Redux: Don't mutate data, 90% of messups I see with fresh people is breaking this. Everything should become transforms! To accomplish this the spread operator (...) in JS/TS along with map/reduce/filter are your biggest friends. (You can do optimizations but 98% of the time you won't work on big enough datasets that you need to do that)
Thus when you do setX (of state hooks) you set your transformed data, same with sending messages in Redux, your Redux reducer acts upon a message to transform the internal state.