首先
项目分析
2.1 需求分析
首页我们拿到一张原型设计稿.
从原型设计稿看出,我们得到以下的需求:
注: 左边的待办项称为‘待办事项’,右边的内容部分文字称为’待办单项‘
- 查询所有待办事项,待办单项
- 新增,修改待办事项
- 删除,锁定待办事项
- 新增,修改,删除待办单项
- 未完成的待办单项的计数
根据这些需求,我们可以先想一下我们这个原型设计图上面包含了哪些显示的数据,和隐藏的数据呢?
2.2 数据分析
显式数据:
- 左边的待办事项标题
- 右边的待办单项文字内容
- 未完成的待办单项数目
隐式数据:
- 待办事项 ——> 锁的图标
- 待办事项 ——> 删除的图标
- 待办事项 ——> 唯一标识(id)
- 待办单项 ——> 删除的图标
- 待办单项 ——> 是否已完成的状态(完成后,前面会打勾,文字中间有横杠)
最终根据上面的分析,我们得到一个单条待办事项应该有以下数据。
{
id: String, //单条待办项唯一标示
titie: String, // 标题
count: Number // 未完成待办项数目
isDelete: Boolean, // 是否删除(物理删除)
locked: Boolean, // 是否锁定
record : [ // 代办项纪录列表
text: String, // 文字内容
isDelete: Boolean, // 是否删除(物理删除)
checked: Boolean // 是否完成
]
}
非常简单的数据结构,你是否和想的和我一样呢?
2.3 api分析
仔细的看上面的原型设计图,我们仔细想想,完成这样的数据需要几个接口呢?
我们在分析一个页面需要的接口时候,我们可以从分析用户产生的 action(即动作行为)下手,就是你想像一下,如果你是一个用户,你进入到这个页面,需要看到什么样的内容,和执行怎么样的操作。
- 首次进入页面,查看待办事项列表
- 点击新增按钮,新增一个待办事项
- 点击一个待办事项,右边显示待办事项的详细内容
- 点击标题,修改待办事项标题
- 点击删除图标,删除待办事项
- 点击锁定图标,锁定待办事项
- 点击加号图标,新增待办单项
- 点击待办单项内容,修改待办单项
- 点击待办单项旁删除图,删除待办单项
- 点击已完成已经完成按钮
从上面对用户的action,进行分析,我们得到了10个需要与后台数据交互的动作。这样我们就可以知道api接口是什么样子的了?
我理解api接口
注: 下文中的 api 指接口名,params指传入数据,data指返回数据
待办事项列表
api: /todo/list (get)
params: {}
/**
* 左边的列表肯定是一个数组对象,考虑到我们每点击到这个标题,
* 就会调转到详细,所有需要id来作为标识进行跳转,
* 在根据图上,标注好的标题,数字,锁定图标,得到下面的标题
*/
data : [
{
id: String, //单条待办项唯一标示
titie: String, // 标题
count: Number // 未完成待办项数目
locked: Boolean, // 是否锁定
},
{...},
...
]
新增待办事项
api: /todo/addTodo (post)
params: {}
//这个接口没什么好多说的。
data : {};
单个待办事项查询
api: /todo/listId (get)
params : {id : xxx} //传id
/**
* 返回待办项的所有数据
*/
data : {
id: String,
titie: String,
count: Number
isDelete: Boolean,
locked: Boolean,
record : [
text: String,
isDelete: Boolean,
checked: Boolean
}
修改 待办事项标题,删除,锁定待办事项
api: /todo/editTodo (post)
/**
* 虽然这里有 修改,删除,锁定三个操作,但是他都是修改单条数据,所有*我们可以合并在一个接口
*/
params: {
id: String,
titie: String,
isDelete: Boolean,
locked: Boolean
}
data : {}
新增 待办单项
api: /todo/addRecord (post)
params: {}
data : {}
修改,删除,完成待办单项
api: /todo/editRecord (post)
/**
* 虽然这里有 修改,删除,完成三个操作,但是他都是修改单条数据
* 所有我们可以合并在一个接口
*/
params: {
text: String,
isDelete: Boolean,
checked: Boolean
}
data : {}
2.4 组件分析
什么是组件?等等系列问题我就不在这里讲了,可以看 《什么是组件化开发?》
vue的组件一般分为如下4种:
- 接入型 比如说一个容器组件,它里面包含了其他的组件,它本身只承担一个布局容器的作用
- 展示型 纯展示型的数据,它能接收数据,展示出来,但是无法与用用户进行交互
- 交互型 比如各类加强版的表单组件,通常强调复用
- 功能型 比如
<router-view>
,<transition>
,作为一种扩展、抽象机制存在。
知道了这4种组件,那么我们结合上面的原型设计图,改怎么划分呢?得到下面几点:
- spa应用本身就是一个大组件
- 里面的布局是一个组件,它里面包含了其他组件
- 左边标签列表是一个组件,包含列表,新增
- 右边单个待办事项算一个组件,它包含上半部分,下半部分。
- 待办单项是一个组件,因为它要被循环很多次
最终我们得到:
app.vue // 最外层根组件 接入型
layouts.vue // 布局组件 接入型 接入其他组件
todos.vue // 左侧列表 交互型组件
lists.vue // 右侧内容 交互型组件
item.vue // 待办单项组件 交互型组件
好了,今天我们项目分析,前期准备工作就到这里,下一章开始就是代码的实战。
看完文章的各位童鞋可以帮我去github帮我点star可以吗?O(∩_∩)O,谢谢,😘,有什么问题可以加群,直接找到我向我提问。
页面做的简约漂亮!