|
作者：董伟明，来自原文地址
效果图：
PS: 本文是假设你已经看过微信小程序的官方文档、demo甚至已经动手写过小程序，否则建议先去翻翻再来看。
设计目录结构
我在上一节知乎Live全文搜索之微信小程序实战（一）/)介绍了组件化，今天就是要实施了。首先我们考虑一个只有index页面的小程序的目录结构是怎么样的：
1
2
3
4
5
6
7
8
9
10
|
├── app.js // 全局的脚本文件
├── app.json // 全局的配置文件
├── app.wxss // 全局的样式文件
├── pages
│ ├── index
│ │ ├── index.js // 脚本文件
│ │ ├── index.json // 组件的配置文件
│ │ ├── index.wxml // 页面结构文件
│ │ ├── rating.png // 还有其他的图片..
│ │ └── index.wxss // 样式表文件
|
pages目录下有个index目录，存放了名字叫做index，后缀为js/json/wxml/wxss的四个文件。这样做的好处是：
-
index目录下存放了页面组件所需要的各种资源，就近维护。如果是React，还得通过使用各种loader，用import的方式来用，所以我喜欢小程序的处理方式。
-
当某天不再需要index这个页面，或者要替换成其他的组件，直接把index目录删掉/替换就完事了。
接着我们基于Live搜索，思考下如果页面变的复杂，重要元素多的场景：
-
需要Live、User、Topic三大元素。
-
有些内容是可以重复被利用的，比如评分（就是大家熟悉的星星，5星满分，4.5星次之…）在Live详情页的效果比较大，而在搜索页由于区域小所以小了很多，但是本质上内容是一样的，只不过样式不同。
-
有些内容在不同页面重复出现，比如Live，在topic详情页、用户详情页、发现页都有，而且一样。
那么：
-
评分是一个独立的区域，可以视作一个组件。
-
组件与组件之间应该可以自由组合，所以组件的粒度要细，细到一个组件就是做一件事。
-
单个评分组件拿出来是无意义的，只有和Live信息汇合起来才是一个完整页面。
所以重新定义目录结构吧：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
App
├── components
│ ├── hot
│ ├── live
│ ├── user
│ └── widget
├── images
│ └── rating
├── pages
│ ├── explore
│ ├── hot
│ ├── live
│ ├── search
│ ├── topic
│ └── users
└── utils
|
现在pages的每个子目录下后缀为js的文件就是页面逻辑。比如pages/users/users.js存放了/users/users的页面逻辑。
我新增了3个目录：
-
utils。存放一些用得到的功能性的函数，如和后端通信的api.js，一会我们详细再看。
-
images。存放公共的静态图片资源。
-
components。组件目录，我们把抽象的元素都放在这里，比如评分是一个组件。组件目录下有这些文件：
|
