At my current job we use Redux, though I wouldn't choose it myself (it had been adopted already when I joined). I think Redux is best suited to very large and complex applications, with very disciplined and skilled engineering teams, who talk to each other, refactor code, and have the time to think through things like the correct arrangement of application state, providing reusable selectors. Those teams, of course, would probably also do fine without Redux.<p>If you have a team that writes spaghetti code, or never has time to refactor, or doesn't have effective communication then things will be worse with Redux, because it makes the code much harder to follow (good luck stepping through things in a debugger to see how they work, for example).<p>This is mostly intended as a criticism of people/teams who think adopting Redux will solve problems with the messiness of their code. But I also think Redux is overly complicated and too abstract for 95% of projects. And don't get me started on Sagas...<p>I would recommend setState as far as you can push it, then choosing something conceptually simple like MobX (Or MobX State Tree), React Easy State, or whatever the one from Formidable Labs is. Using Redux correctly is not as simple as it seems on the surface, and it requires real thought and real understanding o t