2019独角兽企业重金招聘Python工程师标准>>> 
1. container和component不是包含和被包含的关系。
光看字面意思，甚至是多数情况下的用法，会让人产生误解。但官方的例子，似乎是故意的，多数是container包含component，但有一个反例：component下的Footer包含Container下的FilterLink.
这应该是编例子的作者故意为之，是要告诉大家：
containers和components不是包含和被包含的关系。他们最大的区别在于，container接受state，然后根据我们自己的需求逻辑，分发(dispatch)相应的action。而components，只负责对不同的state下的属性进行渲染。
2. 数据流向（store，action，reducer，container，components）
官方例子todos实在是很抽象，看了很久才明白数据的流向。
用户操作界面，触发对应的事件（onclick之类的），然后containers（action的分发都写在container）便会经过我们的判断逻辑，分发对应的action。
此时，store便会开始工作，执行action对应的reducer。reducer返回更新后的状态。
然后呢？然后就ok了，components自会变成你想要的效果。
还记得这段代码吗？
<Provider store={store}>这段代码会监听store，当store调用reducer返回新状态后，就会重新渲染收到影响的组件components。
3. 在store中，state是如何被分类存取？
不同的component都有各自的state，原生react都是通过组件对象保存，通过这样的方式存取
this.setState({prop1:"..."})
let prop1 = this.state.prop1但改用react-redux后，container的state都是这么来的
const mapStateToProps = (state) => ({todos: getVisibleTodos(state.todos, state.visibilityFilter)
})很长一段时间想不通这个state是怎么来的，后来才相同，store会自动调用这个方法传入state。
还有个初学者迷惑的地方。与非redux的写法不同，每个对象有各自的state。在redux中，不同组件的状态则用reducer的方法名进行区分，一个reducer有自己单独的state。所以只要声明todos、visibilityFilter的reducer，就可以直接通过state.todos、state.visibilityFilter获取对应reducer的state。这一点跟非redux写法（一个组件一个对应的state）大不相同。