Redux是如何工作的 (一)

凡是用reactjs开发的项目，但凡规模稍微大一些，都很可能要引入redux来管理组件状态的变迁和组件彼此之间的通信，权威的解释和说明当然是官方的这篇文章，但是，但是，但是，这篇长文处处透露着一种玄妙而不可言说的味道，处处是一些principle，best practice，never，absolutely，you should……的字眼，到处是强调，加粗的段落，一些模糊的store，action，reducer之类的抽象用词，我尝试着写篇小文来记录自己对Redux的学习理解过程。

1. 从reactjs本身谈起

正如官方文档强调的，我们只做view层，是的，reactjs利用JSX把UI的开发演进到另一种模式，就个人观点，我并不觉得其比其他基于模版的view技术究竟高到哪里去，有人说virtual dom技术比原来的直接操作dom来得效率高，拜托，它只是节省了dom元素的寻找时间，react使得程序员从数据变化耦合ui变化的面条代码中抽离出来，每个组件保持了极高的内聚性，给使用者带来了极大的方便，使得在view层堆积木式的开发成为可能，每个UI组件的state对于使用者是完全透明的，使用者只要为它设置好初始的props，组件本身可以响应各种事件来改变自身的状态，重新渲染外观。如果每一个组件都不需要跟外界通信，都不需要跟别的组件联动，那传统的state，props便足以对付所有的开发。但是组件之间的通信，这对一个稍微大型的SPA应用来说，都是必须要有的功能。

2. 我们能从传统的设计模式汲取什么

observer/observable，Event Listener是我们最常用的手段来注册，监听，响应外界感兴趣的变化，假设react组件A监听了组件B的变化，当组件B变化时它调用A注册的回调函数，同时把自己的state传递给B，注意，这里已经完全破坏了组件的边界，当A拿到B的state时，它可以做任何修改，所以实现时，B应该clone了一份自己最新的的state给A，那么问题来了，

1. A组件必须理解B组件的实现细节，不然它没办法理解B的state的含义，但state本身是应该对外界透明的。

2. 每个UI组件都必须暴露注册监听的接口

3. 大量的state复制操作

我们想一想如何自己解决这些问题，

1.  想不到，是的，真的想不到啊

2.  加个属性，不好办啊，A,C组件都想监听B的变化怎么办？

3.  前两个解决不了，这个就不是个问题啊

3. Redux 是怎么解决问题的

1.  计算机问题总是可以通过分层来解决，Redux引入了一个称之为store的层，所有的组件不再维护自身的状态，所有的状态都在这一层来维护，作为一个best practice，Redux推荐用扁平的方式来为维护这个store，所以每个状态都必须小心命名以防止同名冲突，一般的我都会加组件名作为前缀。

2.  既然组件不再维护状态的变化，那么组件的渲染必须通过组件属性的变化来完成，所以Redux在原组件外面重新包了一层，然后外层通过更新内层属性来触发内层UI的重新渲染，内层组件所有的数据通过props来绑定，同时调用通过属性传过来的回调函数来与外界通信，所以组件本身的内聚性得到了保证，组件总是通过属性来工作，需要特别指出的是，组件本身并不需要知道是否工作在Redux的上下文，它只是根据自身的业务逻辑来调函数，所以Redux本身也不需要必须和reactjs绑定，这个外部组件传进来的回调函数一般只会dispatch一个action，action本身只是一个必须包含type属性的普通javascript对象，所谓的reducer就是actionlistener，它根据action的type来更新全局的store，很显然reducer针对同一个action会有多份实现，比如A,C组件对于B组件dispatch出来的同一个action有不同的反应。

（未完待续）