Some great ideas, especially the examples of breaking down UI into smaller components. Thanks for writing this.<p>I've been using Flux to manage pretty much all of the application state, and pass it to the top-level component and down through the tree of components as props. This idea was very well described in an older article[0]. I would add that this approach makes shouldComponentUpdate very important, since more of the tree is rendered on every change.<p>Your example of the dropdown state is a great counter-example where Flux is not necessary or even helpful, and in fact I've used the same example when explaining it myself.<p>One thing I'm not sure about is whether the save action should use a callback (or Flux ActionCreator), or whether it should be triggered by comparing the values in componentDidUpdate as you suggest. Making that behavior declarative is certainly appealing, but I'd be worried that an action like a save could be idempotent, with unpredictable side effects, and therefore makes more sense to be explicit/imperative? I'm not sure which one would be easier to work with at very large scale, and it looks like your application is larger than any of mine, so perhaps the declarative style works better. If anyone has more to say about this I'm curious to hear opinions.<p>[0] <a href="http://aeflash.com/2015-02/react-tips-and-best-practices.html" rel="nofollow">http://aeflash.com/2015-02/react-tips-and-best-practices.htm...</a>