flux redux

1. View-Controller是root组件，是UI中面向Store的接口。
2. 有了flux,View上的交互只产生Action(通过调用actionCreator),类似水中轮胎破洞冒出的气泡。
3. Action 命令模式的command，命令模式：把请求封装为对象，从而分离请求的发起者和请求的接收者（执行者）之间的耦合关系。在命令被执行之前，可以预先往命令对象中植入命令的接收者。
3. Action由Dispather捕获，Dispather根据Action的type判断如何操作Store，因此action-creator命名可能适合与type相同，且表达action的目的。
4. Action是对Event更高层次的抽象，对比传统的从View中直接发起操作(当然，通过VM或者C)，我认为action更加直击本质，而直击本质的结构往往更加健壮：如果用市场来做个不恰当的比喻，MV*就是当市场受到外力影响时，市场的一部分自发地向有关部门反映”你该怎么怎么做”，然后有关部门不假思索地依照市场的指示调整政策；而flux中，受到外力影响的市场将表现出各种“迹象”也就是Action，比如物价升高，CPI降低等等，有关部门成为Dispather，将所有Action捕获，然后对Action展开分析应该如何应对，再调整政策。
5. action机制使得耦合度再度降低，debug更加容易。
6. redux中 一个新的action对应产生一个新的state，清晰可回溯。
7. reducer把一切对state的操作规范化。
7. 一个store必然和一个reducer绑定，这意味着它的state的变化被严格限制，非常的“可预料”。
7. dispather是枢纽，将state，reducer，action编织起来，更重要的是，它是一个缓冲层：当我们想对数据流加一些自定义的功能时，对dispatch做手脚即可，如此可以不影响reducer、action的纯粹性。
8. middleware涉及函数式编程的柯里化和compose：柯里化用于根据当前store来定制可通过compose来改造dispatch的“套接件”；然后把这些“套接件”用compose和dispatch连成一条管道。
9. middleware可以在reducer前、后做些手脚：比如说截流，如果传入的参数不是action而是function或者promise则跳转到另一种针对异步操作的处理。
10. applyMiddleware(m3, m2, m1)作为createStore的第三个参数，是柯里化的中间产品，是一个return函数的函数。函数式编程提倡一个函数只有一个参数，因此中间件是柯里化的。
11. action-type与reducer-case一一对应，这样的解耦在需要变动功能的senario下，产生了灵活性：大部分情况可以对应这三种解决方式，1.只需要改变组件发出的action-type，2.只需要改变reducer-case对state的操作 3.只需要改变action-type与reducer-case的映射关系(且仍然保持一一对应)
12. React v16中，render之前的生命周期函数有可能被调用两次，所以它们应是纯函数