You are conflating two ideas.

Game developers protect state to prevent cheating. For example, allowing a player to update his location could allow teleporting or spawning tons of bullets\projectiles

If a web developer creates an IM webapp, why should they care if you modify your local copy of the message data? It only affects your session and the next time you get a copy of the message it will be the original. All other users are still seeing the original

I don't see any of what you said is opposite to what I said (Local message is just for sake of displaying)

I think we meant the same thing.

"Global" state should live on server. Only local state lives on client. I'm not sure how you are against react, angular, etc, since they only manage "local" state.

I know any framework or any single line of code on client is all about "local" state. But when people lost focus they _potentially_ couple business logics, local truth and constraints with "Global" state from servers, and trust wrong source of truth. And that might end up with next corrupted, e.g. POST, requests.

But then you're essentially talking about BAD code.

Bad code is bad; in any language or framework.

Don't blame the knife (in this case React/Redux or w/e), blame the person wielding it.

If the knife has a sharp handle, it is to blame. Many frameworks have common pitfalls. I've got no opinion where these are in React/Redux though.

> If the knife has a sharp handle, it is to blame

Agreed, this is a good example.

I am trying to avoid blaming React/Redux specifically because it's going to end up with a blog post. Tree nodes communication, composition and state.

Imagine you have a 5-height tree, each node is an object that can receive properties from its parent (hell yeah, lightly inheritance smell), that's not that bad until all objects' methods (components' callbacks) execution orders come together (hell yeah, lightly recursion smell in _imperative ways_ while a normal recursion can be done in declarative way of thinking). Next turn, Redux. Connect a store to any level of tree you want, ahh that sounds handy but I have no ideas who setState, when and where. Saga|Thunk hmm this is slightly better since it is a separate middleware but wait, it's not completely isolated, anything _available_ for you there; Dispatch, Store, setState etc. Finally, all these built on top javascript ahhhh I personally suck at orchestrating these things.