My recommendation is keep hooks and contexts for ui state only, like form fields/validations, modal popups, drawer collapse, filter options, etc, but for things dealing with more general application state which the ui will display, like user information, products list, project data, application settings, etc, a separable state machine should be used. This works well because components are responsible for their own state leaving the state manager clean from individual ui component information, and ui components are free to be passed whatever data improving reusability.
The special sauce, in regards to seperation, is that it can be wired into the component tree without passing it down, which is a property of provider/context and not redux itself.
Sorry, I don't follow. When using Context, how does the application state become dependent on Components any more than it is with Redux? You can accomplish pretty much the same thing with far less code.
Can you provide an example?
How can it be definitely not true, when you have to say "especially"? Most code I've seen (including the official docs) don't data fetch in reducers. But even then, I'm not sure what you mean.
> It also provides a single, centralized store instead of needing many contexts...
Which you can very well do with useContext and useState.
It also provides a single, centralized store instead of needing many context's and lets you abstract data shape/formatting logic away instead of having it in your application.
Context and State are great, but they serve a different purpose than Redux.