I'm just not buying this argument. People add Redux to projects because they intend to use it, and there's almost never a case where a piece of data is actually needed in enough places that it should be global. It's certainly not common enough to justify importing a whole framework for managing global state.
Could you explain what you mean by this?
My intuition here is that what you're saying is true in a trivial sense, but that most state CAN BE (and should be) local if you're breaking your programs into reasonable building blocks.
All that information exists only once and is needed in many parts.
I think many people could argue that this concept itself is a bit misguided. There are plenty of application patterns and architectures that help you move stateful data around your app and translate it for the components who need to consume it or change it, while hiding it from components in the tree which do not interact with or care about the state.
If you have many different components in your app that all need access to the same state data, and they exist at different levels in the hierarchy, maybe you need to re-think your component structure rather than figure out a way to inject mutable global state everywhere?
I think these debates about global variables or state could be much more specific, though.
For example, we tend to realize that letting any component access a `require('./store').currentUser` singleton may make testing harder, but this global dependency still exists when, say, it's distributed to all components through the React context. I reckon most people are thinking of the singleton example when they lambast Redux but it certainly doesn't have to be that way.
