添加样式预处理器loader

默认情况下没有样式预处理器的loader ,我用的scss,不加会报错,所以需要

  1. npm i sass-loader node-sass --save-dev

新建布局、页面、组件文件夹

  • layout
  • pages
  • components

其中根据需要,layout文件夹下可以考虑如下配置:

  • main.vue
  • side.vue
  • header.vue
  • scripts.vue

pages根据需要,如果简单的,可以直接子集为具体页面,如果复杂的,可以针对业务设置二级文件夹。(如果你具体的页面也是比较复杂的建议也是以目录的方式维护相关文档)

  • goods(goodList,goodDetail,goodEdit)
  • setting

components根据需要,优先考虑只设置一些纯ui的封装组件,如果组件内需要比较复杂的,只是当前组件需要的资源,建议在组件内建立文件夹,在组件内进行管理。比如element的alert为例的单组件配置目录,配置src目录管理所有依赖组件,在index.js中进行导出。(如果你的项目中有很多典型的业务组件,尽量将其单独建立一个文件夹,名字可以是kk-components,或者增加组件的命名空间)

vue-cli脚手架之后的待办清单 - 图1
在alert/src目录下维护该组件的主组件,依赖组件,以及其他需要的资源

vue-cli脚手架之后的待办清单 - 图2

默认情况下没有请求模块配置

一般需要使用axios,针对axios进行一次请求的封装,进行一些自定义的项目配置,包括请求时长、baseurl,需要进行的请求前后的数据处理和拦截,针对errcode做的业务化处理等。

其中,根据自己的历史经验,一般情况下,有些特殊请求也是需要单独处理配置的,下面的这些都需要你约定规则,甚至但都一个模块文件去全局维护。

  • 下载文件的配置其对应的部分需要额外设置请求和响应类型;
  • 针对长时长的个别接口需要单独配置;
  • 针对需要携带token或者加密规则的需要单独配置等
  1. const transformRequest = (data = {}, headers) => {
  2. if (typeof data === 'string') return data
  3. const loginId = getUid()
  4. return JSON.stringify({...data, loginId})
  5. }
  6. let _axios = axios.create({
  7. baseURL: apiProxyUrl,
  8. headers: { 'Content-Type': 'application/json' },
  9. transformRequest: [transformRequest],
  10. timeout: 10000
  11. })
  12. // 配置返回拦截器
  13. _axios.interceptors.response.use(function (response) {
  14. return response
  15. }, function (error) {
  16. if (error.response) {
  17. console.warn(error.response)
  18. return Promise.reject(error.response)
  19. } else {
  20. return Promise.reject(error)
  21. }
  22. })

增加services的全局配置

你可以理解为就是业务api的方法配置,一般情况下我们在请求接口的时候不建议具体页面直接调用get/post方法写url地址,传递参数,因为这种方式导致对接口的调用非常零散,不易于维护和统一处理。

所以一般情况下,我们会针对后端不同的微服务,设定不同的api模块文件,如果后端没有这样的设置,你也可以进行一些api的分组维护。

比如后端与用户相关的维护到services/userApi.js,订单相关的维护到services/orderApi.js,然后把通用的get/post方法定义到services/index.js中,在index.js中定义一些你认为常用的api。

关于具体使用,我自己推荐的方式是针对具体业务进行依赖引入,因为一般情况下,我们一个页面只会针对最多2-3个业务。所以我使用的方式是这样的。

  1. // orderApi.js
  2. import api from './api';
  3. // 该模块特有的请求地址前缀
  4. const module = '/order';
  5. import qs from 'qs';
  6. export const orderInfo = (params)=>{
  7. const query = qs.stringfy(params);
  8. api.get(`${module}/orderInfo?query`);
  9. }
  10. // 组件内使用
  11. import orderApi from 'services/orderApi';
  12. import userApi from 'services/orderApi';
  13. orderApi.orderInfo(params).then().catch(error=>{})
  14. userApi.xxx(params).then().catch(error=>{})

你也可以使用另一种方式,将所有的api的维护模块依赖导入到index.js中,然后解构。

  1. // services/index.js ,
  2. //下面的这些手动引入,你可以写成根据services/modules/xx.js的规则自动生成,看具体团队里工程化的程度了
  3. import orderApi from './orderApi';
  4. import userApi from './orderApi';
  5. export default{
  6. get,
  7. post,
  8. orderApi,
  9. userApi
  10. }
  11. // 具体组件中的使用
  12. import {orderApi,userApi} from 'services/index'
  13. orderApi.xxx(params).then().catch(error=>{})
  14. userApi.xxx(params).then().catch(error=>{})

enums 枚举数据文件

主要是用来维护各种业务中的枚举数据的,因为一般情况下,各个业务的页面,或者业务组件的页面都是会不断的重复使用一些枚举数据,而为了方便全局使用和查询维护,一般情况下是建议两种方式:一种是维护enums的文件夹,一种是针对特别固定的枚举独立申明模块,使用方式和第三方库模块一样。

比如enum/order.js的内容格式可能是如下的:

  1. /*
  2. * 订单状态字典
  3. */
  4. export const orderStatusDict = {
  5. 1:'待发货',
  6. 2:'待付款',
  7. 3:'待派送',
  8. 4:'待收货',
  9. 'default':''
  10. }
  11. // 组件或者业务中的使用方式
  12. import {orderStatusDict} from 'enum/order';
  13. // 字典的使用方式
  14. console.log(orderStatusDict[orderStatus || "default"])

全局的filter目录

一般情况下,vue提供的一些工具化的过滤器是不够使用的,所以我们应该再次将过滤器灵活使用起来,主要包括对数字、中文、运算、格式化的进行一些封装,并且混入或者申明到vue原型中。这种直接整个项目可以使用。

另外,在针对制定业务的情况下,也需要一些业务的过滤器,当然过滤器本身就是方法,所以我们应该维护一些针对业务过滤器的方法,至于过滤的规则,可能是业务逻辑,也可能是针对上面提到的枚举数据。使用方式是按需引入,配置到对应组件的filters即可。

assets

针对常规的资源类型,创建一些需要的资源分类文件夹,基于整个项目都需要的维度。比如图片,js库,图标等

utils/libs 维护自定义库或者方法

一般情况下,如果工具不是很多,建议封装到index.js中,尤其是针对项目需要的一些业务弱耦合的工具函数,比如简单的标准化时间。

而对于如果第三方库已经存在的,需要进行减法的,也可以进行封装重新定义。比如像防抖函数,虽然有,但是我们在使用的时候,可以固定一些时间参数,使用场景等,封装之后使用会更加简单。

对于一些处理文件类的也可以定义到这个文件夹下面,比如处理音频的,读取表格的等

@符号没有提示路径

在js中的提示需要加jsconfig.json,配置如下即可,需要软件重启之后生效

  1. {
  2. "compilerOptions": {
  3. "target": "es2017",
  4. "allowSyntheticDefaultImports": false,
  5. "baseUrl": "./",
  6. "paths": {
  7. "@/*": ["src/*"],
  8. }
  9. },
  10. "exclude": ["node_modules", "dist"],
  11. "include": ["src"]
  12. }

mixins 混入

默认的mixins,你一定有很多工具方法和数据需要全局配置使用。这个是在做项目架构时必要考虑的。