前言

上一篇讲完了vue基本功能的完善, 这一篇就讲一讲关于项目的整理与代码的书写规范, 这一部分的话, 样式是参照bootstrap的css规范, 其他都采用见名知意的规则.当然, 还是那句话, 每个人自身理解的不同, 我这边就是分享下关于我的见解, 希望能给到大家参考帮助, 也希望有不足的地方能够在评论区给出, 一起学习, 一起进步

正文

一. 公共组件提取

​ 1. 在项目开发中, 我们会遇到在多个页面中同时存在相同的组件结构, 比如说后台管理系统中的表单, 搜索框等等, 这个时候 , 为了精简我们的代码, 我们可以对单文件组件中的相同部分做一个提取封装, 通过引入来调用, 这样可以使我们的代码不显得太过于冗余,

比如上述中, 一般在项目中, 我们都会在src下创建一个components文件夹, 作为存放公共组件的目录, 其中detailView是详情展示部分的公用提取, PageCommon是分页器的公用提取

详情展示

分页器

拿这两个举例, 都是后台类型项目比较常见通用的功能, 所以可以提取出来作一个简化.

这里, 我就按照个人理解, 简单的总结下公共组件的提取规则:

1. 提取部分是基本通用类,适应性高, 若在某一组件中需要特殊需求处理但又会影响其他组件的使用,则不作提取

   它的含义在于, 我们提取的代码块, 一定是能在不同页面组件中同时使用的, 如果说某一个组件中,它的一部分代码块和其他组件的重合, 比如说表格, 但它的表格又需要作特殊处理, 这个时候, 在初步提取的情况下, 是建议单独使用,不进行提取的, 当然, 也可以通过完善判断,让提取的公用表格组件能够按传递参数分类型展示, 这样也可以. 这个的话相对而言思路复杂了一些, 就在这不细说了, 主要还是讲讲简单基础的提取, 先有个基本的概念, 就是为什么要进行公共组件提取

2. 组件封装, 其实组件提取的过程也是一个封装的体验过程, 建议是先做一个初步提取类型的提取封装, 主要目的在于理解在组件封装过程中的, 数据传递, 循环渲染, 类型判断等等, 这一块的话, 其实我的建议是分三步走.:

   第一步, 做简单的基础类型组件封装, 在这个阶段, 主要理解父子组件传参接参, 以及相互之间的函数调用,

   第二步, 做循环遍历类型的组件封装, 主要理解在数据循环中, 如何针对需要的项进行数据修改或者其他特殊操作.

   第三步, 做数据类型判断的组件封装, 比如通过传递的值类型进行table表格的行合并, 主要理解在封装组件中, 如何去通过值类型的判断去满足多样性功能.

3. 组件封装后对于封装组件的数据源进行初步提取, 可以看下面一点 项目工具函数的统一处理

二. 项目工具函数的统一处理

​ 这个的话, 就比较简单了, 没什么太难的地方.就大致上列举几点

1. 数据源信息的统一提取,

   比如上述中, table表格都会接受一个tableData作为数据源, 那么我们可以在src下创建一个utils目录去存储这方面的统一信息.

2. 项目工具函数的统一提取

   项目工具函数,这个指的是项目中经常需要使用到的函数, 比如说去除空参数, 正则校验判断,时间格式化转换, 对象深克隆, 全局使用的通用函数, 多组件同时使用的相同函数, 等等, 因人而异, 这里我就不放截图了, 理解一下工具函数的意义就行了,具体怎么操作, 看个人.

3. 第三方插件的替换引入

   第三方插件的引入, 其实这点不是太重要, 这里提一下的原因在于, 有些第三方插件其实可以通过工具函数来进行替换, 这样就非必要引入对应的第三方插件了. 可以减少webpack构建时间. 比如说时间格式化经常用到的moment.js , 其实在整体项目中, 可以使用一个工具函数去代替, 这样就可以减少一个第三方插件的引入. 当然, 至于替不替换, 这个还是看个人, 只要不是太过多的引入, 问题不会很大.

三. 内存变量的创建与销毁

​ 这块的话,因为浏览器本身采用的自动清除机制, 比如说标记清除、引用计数, 不了解的同学可以百度一下就可以看了, 这一块的话, 我们在组件内部的destory销毁阶段主动清除的话, 对于浏览器缓存来说会比较友好, 当然, 不进行手动清除的话, 过一段时间, 它本身也会去清除. 所以这里就不细讲了, 主要说下几个清除的方向

1. 定时器的创建与销毁
2. 变量的重置与清除
3. 组件的监听事件的清除

四.代码的书写规范

在我们的项目开发中, 代码的书写规范是相当重要的, 这个不仅是方便自己的阅读开发, 也会对后期其他人员的维护与理解有相当大的帮助. 在项目开发中, 规范很多, 这里就挑几个重要的点讲一下

1.文件名, 变量名, 参数名, 及方法名的书写规范

​ 这几个放一起, 是因为它们都是依照见名知意的规则去进行书写, 一般而言是使用英文翻译去定义, 使用驼峰形式命名. 英语不太好也没有关系, 可以使用百度或者谷歌翻译就行, 我也在用,哈哈, 确实还可以的.

截图就不放太多了, 主要就是遵循让人看到容易理解是用来干嘛的就行, 比如说: 不要去把参数随便定义成 a, b , c 这种, 虽然这样当时开发的时候确实很方便, 但后续维护的时候其实是不容易理解的.

2.注释及书写注释规则

注释遵循的原则就是简明, 直白, 作用明确, 注释的地方主要有下面几个:

1. 成员变量, : 作用在于对变量进行注释, 方便查看不同变量的作用及含义

2. 方法逻辑: 作用在于针对方法中重要的复杂的业务逻辑代码部分标记注释

3. 关于注释的第三点, 我这里希望着重的讲一下, 就是在我们进行一个业务逻辑的开发中的时候, 其实可以先将每一步的步骤用注释先书写出来, 然后依照步骤去做, 这样的话, 一是在书写注释的时候, 可以让我们针对这个业务逻辑的功能实现有深入的理解, 二是不容易忘记想好的思路. 对于后期的维护而言也更加简单, 我觉得这对于我们进行项目开发是非常有帮助的

五.样式的提取及样式的书写规范

1.样式提取

在我们进行单文件组件开发的时候, 如果在每个组件内都用style标签去进行添加样式的话, 其实维护起来是非常不方便的, 所以, 进行样式提取 在项目开发中, 是非常有帮助的,

样式的提取非常简单, 通常我们会在src下创建一个style/styles文件,单复数看个人喜好, 然后在这个文件夹下, 会有一个common.scss/main.scss 来设置一些通用的样式以及重置默认的样式. 那么, 在这个文件夹下, 我们就可以创建不同的文件, 来对应各个单文件组件, 然后再在对应的文件中引入就可以了

这里需要注意的细节就是,为每个单文件组件的父根元素设置一个唯一的类名, 然后使用sass层级类样式定义就可以了.

2. 样式书写规范

​ 1. 首先, 列举几个注意的细节点:

​ ① 定义class类名时, 单词之间应该以间隔线分隔类名, 不采用驼峰式, 简写的话, 也需要遵循见名知意

​

​ 比如上述的, btn的简写, 一般都能识别, 又或者pro对应product, 类型,等等

​ ② 尽量避免使用行内样式. 因为这样维护起来会比较麻烦. 能不用就不用,直接使用class类名代替

​ ③ css中能用padding实现的效果尽量不用margin去实现,

​ 1.相邻的 margin 存在重叠问题，如果能用 padding 实现，那重叠通常会是未预期的副用；

​ 2.如果存在 box-sizing: border-box; 那么 padding 通常无需设计人员额外计算对整体尺寸的影响，而 margin 需要。

​ 3.除了 margin 塌陷以外, 还可能导致一些BUG,doubled float-margin, margin 负值 隐藏3px bug , 等等.

2. 样式书写规范

​ 首先, 我这里采用的样式书写规范, 是参照bootStrap的css编码规范, 链接放在这https://www.runoob.com/bootstrap/bootstrap-css-codeguide-html.html, 这块其实都还好理解, 我就总结几点,

​ 1. 定位类属性放第一, 盒子模型类属性放第二, 其他内部属性放后面

.declaration-order {
  /* Positioning */
  position: absolute;
  top: 0;
  right: 0;
  bottom: 0;
  left: 0;
  z-index: 100;

  /* Box-model */
  display: block;
  float: right;
  width: 100px;
  height: 100px;

  /* Typography */
  font: normal 13px "Helvetica Neue", sans-serif;
  line-height: 1.5;
  color: #333;
  text-align: center;

  /* Visual */
  background-color: #f5f5f5;
  border: 1px solid #e5e5e5;
  border-radius: 3px;

  /* Misc */
  opacity: 1;
}
复制代码

2. 单行规则声明

/* Single declarations on one line */
.span1 { width: 60px; }
.span2 { width: 140px; }
.span3 { width: 220px; }

/* Multiple declarations, one per line */
.sprite {
  display: inline-block;
  width: 16px;
  height: 15px;
  background-image: url(../img/sprite.png);
}
.icon           { background-position: 0 0; }
.icon-home      { background-position: 0 -20px; }
.icon-account   { background-position: 0 -40px; }

复制代码

3. 简写形式的属性声明

/* Bad example */
.element {
  margin: 0 0 10px;
  background: red;
  background: url("image.jpg");
  border-radius: 3px 3px 0 0;
}

/* Good example */
.element {
  margin-bottom: 10px;
  background-color: red;
  background-image: url("image.jpg");
  border-top-left-radius: 3px;
  border-top-right-radius: 3px;
}
复制代码

当然, 关于它这边的规范还有很多, 有兴趣的朋友可以点链接进去看,这里就不多细说了

六. 整体界面风格的统一

这一点其实无关紧要, 因为正常来讲我们是会有ui负责界面设计的, 这里就简单说一下,如果没有ui的话, 我们应该把握的地方点:

​ 1. 整体界面风格偏向简练, 当然, 这个是针对后台类系统而言

​ 2. 主要信息凸出, 次要元素占据空间不应太多, 主要是在主体内容中, 体现更多可阅读性

既然说到这, 就稍微给大家提一下, css中是有视距这个概念属性的,这样我们可以通过控制视距减去固定高度或宽度来做到自适应的变化

 height: calc(100vh - 100px), // 自动填充 视距减去100px的高度
 width: calc(100vw- 100px), // 自动填充,视距减去100px的宽度
复制代码

结语

好了, 关于项目整理及代码书写规范就说到这了, 到这, 基本上我们搭建的项目就初步完成了整体的规范统一了, 后续开发只需要依据对应的规则进行开发就没什么大问题了, 希望能对大家有一定帮助, 还是一句话, 千人千面, 有用的就汲取.

最后, 照例, 加油 , 各位, 明天会更好!