It's lazy to make an ad hominem attack. I write big feature rich react apps without Redux and never hit any situation where I sit around going "damn I need time travel and hot loading and and extra thousand lines of Redux code to remember state."
Try looking at egghead.io tutorials; Dan Abramov has a series showing the implementation of redux and it really is quite tiny. It solves one problem and solves it well: ensuring that components get notified when state changes.
> extra thousand lines of Redux code to remember state
Sorry for yet another ad hominem attack, but this just shows that you are doing something wrong. Yes, Redux requires some amount boilerplate code, but if you need thousands of additional lines of code for state management, then you are lacking code abstraction skills.
I think applications can be architected that don't need it.
You can build an application without functional state management. Of course you can. But, frankly, you can't demonstrate conclusively that you know it's correct or where incorrectness stems from. Which strikes me as something of a problem, and one that does violence to the verb "architect".
I think you're underplaying this. The Redux apps I've seen thread data through a great many layers - action creators, actions, reducers, sagas, schemas - and I think it's fair to say that compared to other projects, Redux apps have very long 'chains of operation' (I want to avoid value-laden terms like 'structure' or 'bureaucracy').
Is it worth it? I'm not sure. The Redux apps I've seen have used this 'highly formalized' approach to handle quite simple interfaces. Maybe I'd have different feelings if I was writing something bigger?
It's not that I hate Redux, or think it out and out 'sucks'; but I've worked on a lot of projects and first Redux ones I've worked on seem unusually difficult to reason about, and a few of my colleagues share my feelings. We feel like it is hard to reason exactly what an event or command exactly 'does', and that the diffusion of behaviour across files plays a part in that.
It is true that if you do Redux "by the book", as taught in the official documentation, then it is indeed quite verbose and confusing in the beginning. But once it makes "click" and you start to understand what the point of all these moving parts is, then it's possible to come up with thin abstractions on top of it to reduce the boilerplate. It would have been great if there was a common "standard" way how to do this, but on the other hand, having the flexibility and power to do things how you want, to make it fit your team and project, is quite nice.
For example, we never liked those huge switch statements in reducers. We just use plain objects, where the key corresponds to the action name, and the value is the reducer function. Not really a big deal, but it just shows that you have the freedom to lay out your Redux app however you see fit.
We also saw no real value in strictly splitting up actions, action creators and reducers among multiple files. We simply put actions, action creators and reducers that belong together in a single file.
And then there is the possibility to use middle wares, which can greatly help in debugging and tracing down actions.
So far everyone in my team is very happy with Redux (and React of course).
I think that's a much more pragmatic approach for smaller applications.
I just became less dogmatic about it. We all have been taught how important it is to separate HTML/CSS/JS, but then came React along and put HTML into JS, many people were outraged, including me. I thought I'd never use that crap that violates basic principles of software design, but here I am and I'm loving it. In the context of UI it makes sense to me. Same with Redux.
Could you please give me an example in which cases you think it could become problematic to have actions, action creators and reducers in a single file? In an application that is not small?