I find flux to be a really bad way to organize an application. It removes the good engineering practice of having self-contained components. So if you're writing a tabs widget you can't put all of its code together, you have to maintain a separate "reducer" or whatever for the tab state in a different file usually in a completely different location, and the top level of the application has to know about that reducer.

I think this architecture is an awful way to go, and I have no idea how it has become popular.

1. Tab state is presentation state, so generally belongs in the component rather than in Flux which is generally for business state.

2. If you do have a tabs reducer, it should be considered part of your tabs component. Use a good boilerplate that sets it up that way, like https://github.com/mxstbr/react-boilerplate

All of the components are totally independent. You pass functions as props for events that happen inside of the component, and choose to use whatever storage mechanism you want. Maybe you don't fully understand how react works.

I was talking about flux. You might have recognized it because I used the word "flux" in the first sentence.

> I find flux to be a really bad way to organize an application.

To be fair, Flux != React. Plenty of people do fine with `setState` and passing down props and you can get quite far. Honestly, I am with you that Flux/Redux ecosystem seems quite overengineered not by their "leaders" and creators (who ask people to keep things simple!) but by regular users. A lot of people solving problems they don't have.

I'm using redux with angular2 at work. Flux != React, and angular2 itself (just like React) does not impose any required data flow or other organization even.