某项目总结

总结项目中遇到的一些问题和解决思路，并不一定有好的解决方式，有些只是纯挖坑，还没找到解决方法

Ajax

问题：

接口区分 GET、POST 等请求类型，但是为什么调用的时候要写明是哪种类型呢？不好记，也不好维护
loading 注入
错误怎么处理（网络错误、abort、404、500...etc），哪些错误需要拦截（登录失效跳转）
如何取消

解决方式一：

使用 axios 封装 ajax，并作为 vue 的插件，方便引用（比如 this.$ajax 或者 this.$http）

api 抽离管理，抹平调用时 GET、POST 的细节（一般来讲，一个项目的 POST 配置是一致的，个别表单数据是否序列化不统一需要特殊处理）
loading 可以使用 iView LoadingBar
使用拦截器 interceptors 处理抛出错误
取消有点麻烦

简单调用示例：

this.$ajax('getUserList', data).then((res) => {
    this.userList = res.data.list
  })

API 抽离

为什么要抽离:

如果 api 分散在代码中，不好统一管理修改。改一个接口需要全局查找，难免遗漏，维护成本高
一个接口可能存在重复调用
不方便数据 mock，重写一遍接口地址、请求类型？（当然 proxy 的时候没这个问题）

将 API 按模块划分，写明地址和请求类型，举个栗子:

index.js 作为 api 的入口文件(因为 import 默认查找的是 index.js，所以入口就不要写成 main.js 那类了)
common.js 为公共 api
user.js 为 User 模块的 api

└─api
  ├─common.js
  ├─index.js
  └─user.js

common.js

export default {
  login: {
    type: 'POST',
    name: '/api/common/login'
  }
}

user.js

export default {
  getUserList: {
    type: 'GET',
    name: '/api/user/getUserList'
  }
}

index.js

// Common
import common from './common'

// module
import user from './user'

export default {
  baseURL: '/index.php', // 前缀
  common,
  user
}

优点：
- api 模块化拆分，方便管理
- api 写明请求地址、请求方式，方便 mock 数据（后端有数据的情况下，使用脚手架的 proxy 会比这个方式更方便）
缺点：
- 同模块下，命名不能冲突，命名麻烦（脑阔疼，命名是程序员头疼的问题之一）
RESTful 情况下，这种数据结构不合适（比如 /:id 的情况）

API 调用

数据获取可以单独封装、维护，需要返回 Promise，方便管理（Promise.all）

普通方式
- ajax
vuex 方式
- dispatch / action

代码规范

Programs are meant to be read by humans and only incidentally for computers to execute.

可以看看《编写可维护的javascript》这本书，挺不错的

代码尽量按模块功能拆分，方便维护

脏代码必然存在，尽量丢到一起

注释，还是加上吧（虽然我也经常忘记写注释...）

后台这种项目基本是永久维护的，不同的人有不同的编码习惯，接手的人多了，风格也就多了

项目中个人还是倾向使用 ESLint，虽然开始用起来，可能大部分错误都是代码格式错误，但是，基本用一段时间就能很快适应

if

使用 === 代替 == 判断数据类型。
如果自己在代码中对于数据类型都不能十分确定，这个代码写的就很有问题。就像改 bug 一样，为什么会出现这个 bug、为什么这样解决、影响范围有哪些都不清楚，往往会改出其他 bug

if 嵌套不能太深：

可读性差
超过两种情况的判断，优先考虑 switch

let、const

消除使用 var 声明变量

let: 声明的变量可以改变，值和类型都可以改变，没有限制
const：用来声明常量，所谓常量就是物理指针不可以更改的变量。只是保证变量名指向的地址不变，并不保证该地址的数据不变（除了不能改变物理指针的特性，其他特性和 let 一样）

CSS 部分

做后台管理后，已经基本不写，也基本不用写 css 了。
虽然 iView 框架已有内置的许多组件样式、栅格化这些基本的都有。但是实际用起来，感觉还是少了一些什么。比如布局、间距调整
然后问题便来了，额外的样式怎么处理。

iView 和 Bootstrap 样式混合

...
import iView from 'iview'
import 'iview/dist/styles/iview.css'

import {Select, Option} from 'element-ui'
import 'bootstrap/dist/css/bootstrap.min.css'
import 'bootstrap/dist/js/bootstrap.min'

import 'font-awesome/css/font-awesome.min.css'
import './assets/css/style.css'
...

看到 iView 和 Bootstrap 的样式混在一起，还是很懵逼的，而且还写了一些自定义的样式 style.css = =
那么问题来了：

为什么需要引入 Bootstrap ？因为用了 Bootstrap 的一些组件，比如 Modal，其实 iView 也有...
为什么又定义 style.css ？因为需要设置一些通用布局，比如页面框架布局、margin、padding 等...

iView 和 Bootstrap 的 normalize.css 版本不一致，其他地方对于某个元素默认设置还是有些出入的，引入会有隐患问题。

瞄了一眼 style.css：INSPINIA - Responsive Admin Theme，一个基于 Bootstrap 3 的框架

感觉这么多混在一起，很乱，如何让接手的人知道如何复用已有的样式是个问题

scoped

当

上述代码将会编译成：

.a[data-v-f3f3eg9] .b { /* ... */ }

有些像 Sass 之类的预处理器无法正确解析 >>>。这种情况下可以使用 /deep/ 操作符取而代之——这是一个 >>> 的别名，同样可以正常工作。

数据流

目前许多公共数据是放在 Storage 里面的，那么：

何时获取公共数据？
- 可以放在根组件 App.vue 里面触发
何时更新这些数据？
- 如果放在 sessionStorage，那么新开窗口打开后，将重新获取数据
- 如果放在 localStorage 里面，那么不手动清除，将一直存在
可以考虑 Vuex

公共数据为了节流，需要避免重复请求，可以存在本地。但是，如果存在本地，则需过期清除数据。那么，何时过期是个很麻烦的问题。就拿公共配置数据来说，配置数据何时被修改，是不可控、不可预期的。设置半天过期，那么，用户拿到的就有可能是旧的数据，会产生错误数据。所以，不如每次登录后，拉取服务端数据一次（重复请求，读取本地数据），存起来，这样请求量也不大，对服务端压力也不大。

vue-router

比起 iframe 的模式，vue-router 还是轻便很多。router 多起来之后，维护也是个问题

路由按模块拆分

路由按模块拆分，建议懒加载的形式（目前 octet 已经是这样了）
每个子节点路由，可以新建一个 index.vue 文件，这样，便可以在这个节点的生命周期里统一做一些操作，比如获取这个节点所需要的公共数据。

component: {template: ''},
children: [...]

转成：

component: () => import('@/views/user'),
children: [...]

vue-router 页面刷新

路由不变的情况下，如何刷新页面？

看之前的代码是写个空白页面做跳板，先跳这个页面，再跳回来
参数或查询的改变并不会触发进入/离开的导航守卫，原来的组件实例会被复用。加 query 参数，比如时间戳

其实这几种我觉得都不是很好，不过也没找到更合适的方式

router 命名

菜单使用 router 配置数据显示，比如 icon、name

目前菜单名称直接读取的 route.name, 可以把菜单名称放到 meta 里面去
- 因为菜单名称作为文案，经常发生变动，而 route.name 经常用于路由访问，不大合适
- route.name 可用做 router.push({ name: 'home' })，虽然 path 也行，但是 name 写起来更简洁，也易于维护 path（路由访问使用 name，当 path 变的时候，只需要改路由配置一份代码就行）
菜单的 active 可以根据当前路由信息计算出来（子路由访问，不会 active 菜单，是个问题，纯路由判断会有问题，matched 目测可行）

路由权限控制

现有权限控制是通过显示隐藏菜单来控制，当用户输入无权限的路由的时候，还是能访问到这个页面，无非完全避免无权限访问的问题。可以拿到权限后，追加一次路由守卫，无权限重定向到无权限页面。
可以先接口获取权限，根据权限动态注册路由（router.addRoutes）。那么无权限，这个路由根本就不会存在，也就不存在访问的问题。不过 router 并不属于响应式数据，所以动态注册的路由并不会在菜单渲染，可以考虑 Storage 或者 Vuex 的方式传递路由数据。
或者，获取菜单权限后，再加一个路由守护，没菜单权限直接跳 404（或者做个无权限提示页面）

浮点数计算

数字计算还是比较危险的操作，可以使用可靠的开源库，避免前端计算所产生数据误差。

表格打印

之前的打印：

let oldstr = $("body").html(); // 保存原始页面的 body 内容

$("body").html($('#print-table').html()); // 整个 body 主体换成需要打印的表格

$("body").css("height", "auto"); 
window.print(); // 打印
$("body").html(oldstr); // 原始页面的 body 内容重新塞回去

如果直接打印，不会出现什么问题。但是如果取消打印，则会报错（只允许一个 babel-polyfill 实例，估计旧内容导入了 js 代码冲突了），再点击打印则无效。

可以新建打印页面，只插入需要打印的表格数据、表格样式，以及打印逻辑，这样便不会报错：

    // 页面的 dom 以及脚本
    const html = `