reactjs和flux的一些疑问

Question

知道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，这个还是有点新引力的，不知道我说的这些问题是由于个人理解不足导致的，还是有其他我不知道的解决方案？

Answer 1

我觉得吧，你可以有几点来优化的：

1. 码代码的正确顺序。 你可以先用react来码基础的代码，即业务框架，如果涉及数据，可以先自己伪造数据，不着急上flux或者redux。

2. 对于程序员来说，一直在变化的不是变化，而是业务需求！所以，你在初期阶段可以自己审时度势，不要一下子把功能写那么细。

3. 至于耦合情况，重用程度，这个跟个人的编程风格有关，即代码经验，全局观，设计模式的使用等有关，这一点是你在熟练使用技术后需要提升的部分，也是凸显个人水平的部分，一起努力吧~

Answer 2

通信还是用消息比较好, 把redux的store.dispatch("xxx" 变成 emmit("xxx", 然后在component里面响应

on("xxx",function(payload){
   changeState(...);
}

Answer 3

路过。很赞同一楼的说法，码代码的正确顺序很重要。再则是Flux绕一圈有绕一圈的好处，你所说的 “表单填写-验证-出错提示/正常提交” 走Flux是一种浪费，可能是你的表单逻辑太过简单的原因吧，如果表单的逻辑复杂了(比如：表单的错误提示会随着输入变化，表单项会随着填写增加减少以及会变化)，你会觉得我靠，一个action就可以做到这么多事情，并且还不用担心后续更新问题。当然对于一些特定的情况，事件机制bind-trigger结合使用会更方便。

Answer 4

我来说说几句，没太多深入见解，就一年多经历。

1. JSX是缩简语法，不用也行。一个档中JSX嵌套过多代表你该拆分成多个档多个组件。模组系统写法善用。

2. 全局store方案依然是用上层传资料到下层，只是自动帮你传而已。另有context新作法，一种实验性质，高度风险的作法，但能力强大，上层组件往下层都自动传，初学者不适用，学过redux或mobx，你可以回过头来学。

3. Flux架构是规模化大架构设计，小应用用起来自然费心。况且Flux不建议再用，原始的Flux库代码零乱，东拼西凑不好用，应该用redux，觉得难学可以用mobx，看文件几分钟就可以飞了，但新产品总多坑你知道的。想处理的事多，就得乖乖用架构才有条理，框架都这样没例外，作大事总是用大思维。

总结是要灵活不要用React，React概念新，旧思维得改，如果jQuery能灵活快乐地作的应用，不要急著换到React，没有比较灵活，只会徒增痛苦。除非你已经把该学的都学了，能够作什么都用React的想法去规划实现了，再来谈要作什么。React有什么好的，网上都有了不多说，如人饮水冷暖自知，没真心想跳坑说有多牛多厉害，实在都是表面，是纸上谈兵尔尔。

我正在用React Native，用过的都知道，坑更多路更长，痛苦必定是React的数倍之多，今天好不容易写好了这功能，明天改版后动作报错了，这家常便饭习惯就好。但新技术不就这样吗？用什么不都一样，你今天改用Vue.js或Angular2，一月一小版，一年半载一大版，久了就不会难过，该来的总会来。不然，去看看Android还Swift，氛围是愉悦的还是叫苦连天的？