注意：扩展 指的是实现一个类似于 奇妙清单 的todos的思考
先设计Redux 的 state
根据应用的功能来设计state的数据存储结构
对于一个todos，有两个数据需要存储：
- 过滤器（就是当前选择显示的todos），如：显示所有的todos、显示未完成的todos或者显示完成的todos
- todos的信息
- text
- completed
- deleted
Redux state的数据结构就是：
{
visibilityFilter: 'SHOW_ALL',
todos: [
{
text: 'Consider using Redux',
completed: true,
},
{
text: 'Keep all state in a single tree',
completed: false
}
]
}
扩展
- 过滤器
- todos的信息
- text：todo的信息
- folder：该todo所属folder
- completed：完成状态
- deleted：删除状态
- createTime：创建时间
- finishedTime：：完成时间
设计component层级（Hierarchy）
Think in React
设计一个web app 的流程
第一步：将UI解剖到 Component Hierarchy中
在这个过程中，应该如何将UI解剖成单个的组件呢？或者说我们如何确定这一部分可以作为一个组件存在？
遵循一个原则：单一职责原则，也就是说一个组件只做一件事
一般来说，如果数据模型合理，那么就很好将数据模型映射到UI组件上，因为UI和数据模型一般都是遵循相同的架构，所以，只需要将数据模型分解为代表UI的各个组件即可
将UI拆分为各个组件之后，要画出组件层级图，表明各组件的层级关系，也就是它们之间是如何进行嵌套的
第二步：Build A Static Version in React
就是将第一步划分的component，按照Component 层级关系拼接成一个没有交互的版本;
注意：不要使用state来构建该版本，state仅仅是为了交互而存在的
构建该版本有两种方式：
- 依照component Hierarchy从顶向下构建，也就是从最上层的组件开始编写
-
从下向上构建，从最底层的组件开始编写
对于简单项目来说，采用从顶向下比较好，而对于复杂应用来说，使用从下向上更加适合
数据从最顶层的component与data model进行通信，然后通过props向下面的子组件传递数据
React遵循单向数据流
最顶层的组件一般都是Container component，而它下面的子组件很大一部分都是Presentation component。
第三步：构建能够反映UI状态的最小数据模型(state)
其实就是设计数据存储框架，也就是model的架构
在React中有两种数据模型（model）：props和state
这时，我们要判断出我们的应用程序中，哪些是state，哪些是props？
首先，列出我们的应用程序所有的数据
然后依照下面的规则来判断哪些数据是state，规则如下：
- 如果这个数据是父组件通过props传递下来的，那么该数据就不属于state
- 如果该数据随着时间保持不变，那么它很可能不属于state
- 该数据是否能通过你组件中的其他state或props计算出来，如果可以，它很可能不是state
第四步：标识出state应该传递给哪些组件
对于新手，这一步往往会很困惑，可以遵循下面的几条规则：
- 如果一个组件需要依靠该state来进行刷新，那么你需要将state传递给它
- 在component hierarchy中，层次结构较高的组件可能需要改state
第五步：增加逆向数据流
因为子组件不能直接更改父组件传递下来的数据，所以，需要为子组件的行为绑定事件处理程序，该处理程序通过父组件传递下去
参考：https://facebook.github.io/react/docs/thinking-in-react.html
使用Redux 和 React
在上面的构建出了最小数据模型之后要开始设计Redux的actions和reducer
网友评论