页面逻辑的页面
正如我们前文所说,“页面”在Vue中是不存在的,它只是一种逻辑上的概念。事实上,“页面”这个概念就是由DOM元素和一个甚至多个自定义Vue组件复合而成的复合型组件。我们应该如何分清楚哪些部分使用DOM元素实现,哪些部分又应该封装为更小级别的Vue组件呢?
首先,我们要从原型设计图入手,可以先从功能性布局上划分出对应的功能区域,如前面的设计图所示。
然后用HTML的注释标记作为页面上的“区域占位”,先给页面搭一个最基本的结构,这就像作画时先给整体打草稿勾一个轮廓一样。当我们一步一步地将这些细节描绘出来后,再将这些“轮廓线”从画中抹掉。
1 | <template> |
封装可重用组件
重复性的内容就可以被提取出来封装成一个或多个组件,但封装之前我们得知道向这个组件输入一些什么样的数据,这个组件应该具有什么样的行为或者事件。
经过第一次的抽象,代码减少了很多,但是这两个Section内显示的内容除了标题与图书的数据源不同,其他的逻辑还是完全相同的。也就是说,它们应该是由一个组件渲染的结果,只是输入参数存在差异,那么就还存在一次融合抽象的可能。此时我们就可以动手将这两个列表封装成为一个Booklist组件。
自定义事件
按照设计图,当用户点击某一本图书之时要弹出一个预览的对话框。
也就是说,每个图书元素要响应用户的点击事件,显示另一个窗口或对话框显然应该由Home页进行处理,所以就需要BookList在接收用户点击事件后,向Home组件发出一个事件通知,然后由Home组件接收并处理显示被点击图书的详情预览。
数据接口的分析与提取
将写死在data内的数据变活,让它们从服务器端获取。
我们先将这些数据抽出来放到一个~/fixtures/home/home.json文件内,然后将data内的数据清空。
1 | data () { |
最后,将与服务器通信的数据接口和API的用法保存到~/fixtures/home/README.md,以下是API文档的样本:
请求地址
1 | HTTP GET '/api/home' |
返回对象
要确保前后端开发的一致性最关键是控制接口。因为它们是前端与后端关键结合点,API接口的任何变化都会导致前端与后端代码的修改甚至是进行新的迭代。
由于前端是消化用户需求的第一站,所以由前端来制定接口是最合适不过的了。因此,我在团队协作式开发过程中最重要的关键任务就是制作上述的这一份API接口说明文件,只有它呗确立之后才能真正地实现前后端的协作式开发。
对于较小的项目我们的做法是将所有的文档保存到项目根目录下的docs内,同时也纳入到Git的源码管理中,方便平时查阅。而对于规模较大的项目我们会使用GitBook编写一份更加完整的手册,文档在设计时编写是最容易的,如果到项目验收时才补充一定会有疏漏,不要让文档成为开发人员的技术债务。
从服务端获取数据
Pagekit创建复合型的模板组件
数据模拟
“数据模拟”就是用一个对象直接模拟服务端的实现返回的数据结果,而这些数据结果是我们预先采样收集来的,与真实运行数据几乎是一样的。通过数据模拟保证前端程序即使在没有服务端支持的情况下也能运行。
将data的样本数据抽取出来保存到了~/fixtures/home/home.json文件中。为了能先让开发环境运行起来,我们可以加入一些助手类来模拟实际的运行数据。
小结
工作流程图:
- 本文作者: LQbank
- 本文链接: http://example.com/2019/07/02/页面的区块化与组件的封装/
- 版权声明: 本博客所有文章除特别声明外,均采用 MIT 许可协议。转载请注明出处!