React实战-ReactJS+Redux的思考

React实战-ReactJS+Redux的思考
ReactJs的官方架构是：ReactJs+Flux。然而作为Flux的升级版，ReactJs+Redux越来越流行，已经有超越ReactJs+Flux的趋势。到底哪种更好，则又是一个仁者见仁、智者见智的事了。但是无论你是否采用Redux，最好还是看看Redux的使用方式，如果能看看Redux的实现方式，将收益匪浅，那是将重构运用的令人敬佩的实际案例(微信：react-javascript)。
1.Redux诞生的原因
对于Redux作者的动机，我也是深有感触的和认同的。采用ReactJs后，我们的确将页面元素都组件化了，大到整个应用，小到一个按钮都是一个个组件，但也带来了相应的问题，太多的状态需要维护，太多的事件关联，再加上对ReactJs框架不熟悉，出现各种不伦不类的编程方式，随着程序代码不断增加，你会感觉慢慢失控，尤其是在规范性不强的开发组里，同样的一个操作，可能每个人的做法都不一样，给项目带来了极大的风险。Redux作者认为最大的风险是：可变性和异步。Redux作者想解决的最重要的是这两个问题，结果如何，只能说Redux作者确实是个大师，在看来Redux最终的实现方式时，你会觉得在封装和解耦这两点做的了极致。
2.Redux的三原则
Redux作者定义了Redux的三原则，这也证明了Redux作者的大师级水准。Redux有以下三个原则：
a.整个应用的state以对象树的形态存在一个store里。
这里关键有两点：一是在Redux中所有的state存在一个对象树里；二是state存在store里。Redux作者的观点是这样简单，易调试、跟踪，开发快、并且使得传统方法很难实现的操作现在很容易了，例如Undo/Redo之类的操作。
对于这一点还真是出乎我的意料，在Flux中虽然state存在于store中，但是在各个组件里也存在大量的state，这种集中将state存在于store中,并且只构建一个state对象的想法跟单页面的想法一样大胆。但是相应的也就带来了很多约束，程序员的自主性也少了。可能这就是简单与灵活的两难取舍吧。
b.State是只读的
只有通过action一个方式才能改变state。这在Flux中基本也采用这种方式实现对store中数据的操作，然而在页面组件中则自由的多。Redux采用这种方式基本上是强行迫使你采用单向数据操作方式，但是给人的感觉有点像带了一副枷锁，限制了你的自由。
c.变化均采用了纯函数式编程
全部采用纯函数式编程，好处自然是纯函数编程的好处，对于这种好处，我感受并不深刻，但是这种纯函数编程的写法还是与普通写法有很大的不同。我一直怀疑这种纯函数式编程方式的性能是否受到较大影响，尤其是在数据集操作过程中，是否明显，没有测过，也就没有发言权了。
3.是否采用Redux
是否采用Redux？这是个问题，正如Redux作者所说，Redux可以看作是Flux的实现，也不全是。Redux来源于Flux，使得模式更简单，在这中简化过程中又增加了一些自己的规则。
4.Redux中的纯函数编程
纯函数编程是Redux与Flux在编程方式中的重要区别，首先看看纯函数编程的要点：
a.同样的输入，得到同样的输出
b.操作不受边界影响
c.不依赖外部状态。
纯函数编程通俗的讲，函数操作过程不受外部影响，同样的输入不会因执行次数不同而不同，在store中最多的是对数据对象和数据对象集的操作，如何才能做到是纯函数编程，有一些通用的技巧，尽量采用Array的map(),filter(),concat(),slice()和...spread操作来实现，避免直接对Array参数的元素直接操作。
以下为添加和修改操作的纯函数式编程方式。
1）.添加操作
Function addText(state,action){
Return [
...state,
{
Id: action.id,
Text: action.text,
Completed:false
}
]
}
 
2）修改操作
Function modifyText(state,action){
Return state.map( (t, action => {
if (t.id !== action.id) {
        return t
      }
 
      return {
        ...t,
        completed: !t.completed
      }
}
)
}
以上操作基本体现了纯函数式的不同编程方式。
5.结束语
最终是否采用Redux，这确实是个问题，在Facebook的一个社区统计结果来看，用的人还是占大多数，每个人的情况不一样，无所谓多好多坏吧，it’s
up to you。