Well you addressed the first big question I had as I now begin to learn React. Why do I need this additional state store maintenance? I don’t use anything like this in Angular 4 and I address state just fine. But there are times in Angular components when I have to work around not having a common place to reference a data change/state change in another component. I don’t like using parent/child references so I just say another related component.
Most of the tutorials I’m running into suggest using Redux. I don’t mind adding an additional outer layer of state this way. I can see it as a viable option. What I’m most concerned with is the ‘standard’. I don’t have time to learn techniques that are not being used out there by the teams I’m planning to join to build these React apps just as I’m doing with Angular.
You do suggest that large applications use options like Redux. Most of the clients north of me where I look for contract work build this gigantic apps and I have of late been asked to jump into the jumble and make modifications. Of course its often like those games where you pull a straw and the stack comes tumbling down on you. A common approach to state maintenance like Redux would at least give me half a chance to fix or extend a feature.
So I think I’ll start with Redux from the get go. I’ve gotten used to building the framework first with the extensions (services or other) for things like security and logging so Redux and app state will be just another layer to reference when you need to following the same pattern across all apps.