知道reactjs很长时间了，也尝试过采用reactjs+redux，但是最后都没法坚持下去，原因有下面几个：
1 jsx：看着满屏的标签+表达式真的觉得没法忍受，不过这个是个人喜好
2 组件嵌套：这是我最青睐的特性，就跟以前喜欢angular的directive一样，通过自定义标签实现组件的重用，reactjs的组件化理念很不错，做一些todomvc的例子很好用，但是实际中发现组件都是要嵌套的，而reactjs也讲究dumb component，这样就意味着一个4级嵌套的组件，数据从最上层传递到最下层是一个噩梦，事件handler也一样，考虑过全局store，组件直接从里面取数据，但是这样子组件就没有可重用性了（我希望的重用性并不是在某个应用中重用，而是能够跨项目重用）
3 flux：随着组件增多，共享状态也增加了，以前通过事件的方式针对共享状态的修改进行组建的重绘制，跟踪调试不是很方便，flux出来了，刚一看觉得理念还不错，就尝试一把，但是严格按照flux的流程实现的话也是个坑。
任何一个操作都要绕一圈，很惭愧，即使做一点微不足道的工作也要大动干戈，拿表单填写-验证-出错提示/正常提交来看，需要往store里面放的的东西太多了，哪个字段出错了、原因、当前是不是正在验证/提交（控制提交按钮可不可用），已经提交的输入（用户恢复案发现场）、是否正在加载（显示进度条）等等，这样子的问题是在开发过程中有一点如履薄冰的感觉，得小心翼翼，你一旦修改了store的shape，必须找到所有用到这个store的component去修改对应的绑定，宝宝心里苦死了。
即使后来有了redux，整个应用状态的shape、reducer等我仍然觉得耦合太近，牵一发动全身，没有丝毫灵活性。想一想，修改一个操作的逻辑，你的改几个地方，component reducer action，我觉得很痛苦，尤其在开发阶段，有时候应用的shape并不确定不变的。
最后，抛开这些耦合不讲，除了component之外，reducer action有哪些是可以重用的？在同样一个项目里面，其实有很多功能逻辑都差不多的，就说最简单的增删改查，不同类别的增删改查，很大程度逻辑都是一样，填写、验证、提交，但是一些细节可能不尽相同，比如提交后的后续处理，有的是跳转，有的是提示，所以想重用那些reducer，action觉得要做许多trick。
上面这些问题是接触reactjs flux遇到的，之所以念念不忘是考虑到react-native，这个还是有点新引力的，不知道我说的这些问题是由于个人理解不足导致的，还是有其他我不知道的解决方案？
我觉得吧，你可以有几点来优化的：
码代码的正确顺序。 你可以先用react来码基础的代码，即业务框架，如果涉及数据，可以先自己伪造数据，不着急上flux或者redux。
对于程序员来说，一直在变化的不是变化，而是业务需求！所以，你在初期阶段可以自己审时度势，不要一下子把功能写那么细。
至于耦合情况，重用程度，这个跟个人的编程风格有关，即代码经验，全局观，设计模式的使用等有关，这一点是你在熟练使用技术后需要提升的部分，也是凸显个人水平的部分，一起努力吧~
路过。很赞同一楼的说法，码代码的正确顺序很重要。再则是Flux绕一圈有绕一圈的好处，你所说的 “表单填写-验证-出错提示/正常提交” 走Flux是一种浪费，可能是你的表单逻辑太过简单的原因吧，如果表单的逻辑复杂了(比如：表单的错误提示会随着输入变化，表单项会随着填写增加减少以及会变化)，你会觉得我靠，一个action就可以做到这么多事情，并且还不用担心后续更新问题。当然对于一些特定的情况，事件机制bind-trigger结合使用会更方便。
通信还是用消息比较好, 把redux的store.dispatch("xxx" 变成 emmit("xxx", 然后在component里面响应
on("xxx",function(payload){
changeState(...);
}