又是一波前端知识点总结

总结的点都杂七杂八，但愿能找到对你有所帮助的，没有的也没关系嘛！????

1. vue 强制渲染某个组件

$forceupdate 使 Vue 实例重新渲染。注意它仅仅影响实例本身和插入插槽内容的子组件，而不是所有子组件。

由于某些场景 $forceupdate 不起作用，所以用下面的 hack 方法。一般来说，这种强制渲染某个组件的情况不多，在组件内部应该处理好内部的渲染。
这个例子还是因为使用某个库后发现了一个 bug，后面才想到以下 hack 方法的。

<my-comp v-if="show"></my-comp>
<script>
data() {
    return {show: true}
},
methods: {reRender() {
        this.show = false
        this.$nextTick(() => {this.show = true})
    }
}
</script>

• 必须用 v -if，v-show 不行
• 在 $nextTick 回调中重新赋值，否则 vue 会忽略 show 的第一次赋值

2. vue 里的 ref 和 v -for 一起使用时，得到的引用将会是一个包含了对应数据源的这些子组件的数组

当 ref 和 v-for 一起使用的时候，你得到的引用将会是一个包含了对应数据源的这些子组件的数组。

<div v-for="item in list" :ref="item.code" @click="handleClick(item.code)">{{item.title}}</div>

handleClick(code) {
   ~~let dom = this.$refs~~ // 错误的写法
    let dom = this.$refs[0]
}

  vue 的一些 api 在特殊情况下会出现不一致的情况，这点比较蛋疼，需要对文档比较熟悉。

3. Gitlab 不仅仅可以作为代码仓库，还可以作为项目管理工具，通过标签，里程碑，提交历史，代码审核流程等。

以后在公司里，如果做项目管理或者 code review 都可以用 gitlab 来做。

4. css 背景图片 background-size 的几种适用范围

css 背景图片 background-size 的几种适用范围

5. 作为 TL，安排工作计划，协调各种资源也是需要花费时间的，这些时间需要考虑在内，必然会减少编写代码的时间。这一点要清楚。

6. 怎么评估工期

• 需求非常明确而且经常这样做：自己评估时间 * 1.5
• 需求不够清晰，有可能变，但是代码和技术方案熟悉：自己评估的时间 * 2
• 需求不够清晰，代码和技术方案也是新的，需要探索：自己评估的时间 * 2.5 or 3

自己评估的时间一般会留点 buffer，自我感觉应该没问题， 实际上开发过程可能会有各种会议、需求和技术方案变更或者突发事件。所以多留一点 buffer 会更好，因为这个时间点可能是下游运营活动上线时间点，评估后业务方觉得太长可以砍需求拆成两期或者调整上线预期，但一旦设置了时间点，不应该跳票 。如果你比预期早完成上线，皆大欢喜，如果你一次次的告知业务方还需要延期一两天，效果正好相反。

7. 无缝滚动组件

无缝滚动组件

8. 前端的工作要紧密结合产品和 ui，整个前端展现出来的效果是三者相互合作创造出来的，而不是某一方。前端的一部分价值不仅仅体现在写代码上面，还体现在和 ui，产品共同创造好的界面和交互效果。

9. 软件具有熵增的特性（体系总是自发地像混乱度增大的方向变化），长期维护的项目总会遇到可维护性逐渐降低的问题。

10. 代码风格统一工具

• 使用 editorconfig 协助兼容开发工具的代码格式化。
• 使用 eslint 检查代码。
• 使用 prettier 格式化代码。（可以理解为 prettier 是 eslint —fix 的加强版，用 prettier 来代替 eslint-fix）
• 手动修改剩下的有问题的地方，或者有些地方很难用规则来判断的时候，就需要手动修改。

11. 使用 husky 和 prettier 统一代码风格

npm install --save-dev prettier pretty-quick husky

package.json 里配置

"husky": {
    "hooks": {"pre-commit": "pretty-quick --staged"}
},

需要注意的事，安装包之后，package-lock.json 也需要提交 commit，否则 hooks 不会执行（不知道为什么）!

12. 使用.editorconfig，一定要用 indent_style = space，如果用 tab，不管怎么设置编辑器，tab 都为 4

13. 提高团队代码质量的想法

1. code review 要更加仔细，保证每个人的代码质量，哪怕进度慢一点（ 同时，自己写代码的时间减少了，但是这样是值得的，如果只是自己写代码，只能保证自己的代码，但是 code review 能帮大家的代码都提高，团队共同提高的效益肯定比自己一个人要大 ）
2. 在 code review 发现的问题，在会议上提出来，让大家商量解决办法，同时避免以后出现相同的问题，这样大家的代码质量都能提高
3. 目前的问题：

• 大家会写大量重复的代码，不管是 js 还是 css，碰到两处以上会调用的代码，应该要封装起来
• 变量命名不按照规范，并且不注意语义化。代码不仅仅是写给计算机执行的，同时是写给人看的，最要命的是给别人看。好的代码，一看变量，就大概知道这个变量是干嘛的，或者方法是干什么的，而不好的变量命名只会让程序出现歧义
• 写代码不注意代码量，一写千里，一个单文件组件能写到 2000 行，方法的行数也要注意。这里建议：单文件组件行数不大于 1000，超出应该要拆分出来；方法行数不能超出 100 行，超出拆分
• 多个 if else 应该用 switch，看起来更舒服，逻辑更清晰
• 拼接字符串尽量用模版字符串语法
• 不要使用 var 定义变量（用 eslint 控制）
• data 方法里不要的变量定义尽量精简；如果是模板里没有使用，不需要在 data 里定义，可以直接挂在 vue 实例上，或者写一个局部变量代替
• 学会使用计算属性，ex:

data() {
    return {
        arr: [{status: true, foo: 1},
            {status: false, foo: 2}
        ]
    }
}
computed {
    // 用计算属性代替，而不是每次手动计算一次
    activeArr() {return this.arr.filter(i => i.status)
    }
}

• Prefer early exit

// bad
function someFunction(someCondition) {if (someCondition) {// Do Something}
}

// good 逻辑更清晰，避免过度 else if
function someFunction(someCondition) {if (!someCondition) {return;}
  // Do Something
}

14. 精读《为什么专家不再关心技术细节》

1. 技术细节学习难度不大，在需要深入的时候再深入了解最佳。
2. 想要做成事，需要更宏观的技术思维，所以专家渐渐变得眼光宽阔，格局很大。
3. 专家拥有快速学习技术细节的能力，只是这已不是其核心竞争力，所以与其写技术细节的文章，比如写方法论的思考带来的价值更大。
4. 指引方向比走路更重要，专家都要逐渐成为引路人。
5. 技术最终为业务服务，懂技术细节和让业务先赢没有必然的关系，所以在深入技术细节之前，要先理解业务，把握方向，防止技术细节出现路线问题。

15. rgba 转 16 进制函数

function hexify(color) {
  var values = color
    .replace(/rgba?\(/, '')
    .replace(/\)/, '')
    .replace(/[\s+]/g, '')
    .split(',');
  var a = parseFloat(values[3] || 1),
      r = Math.floor(a * parseInt(values[0]) + (1 - a) * 255),
      g = Math.floor(a * parseInt(values[1]) + (1 - a) * 255),
      b = Math.floor(a * parseInt(values[2]) + (1 - a) * 255);
  return "#" +
    ("0" + r.toString(16)).slice(-2) +
    ("0" + g.toString(16)).slice(-2) +
    ("0" + b.toString(16)).slice(-2);
}

var myHex = hexify('rgba(255,232,186,0.4)'); // "#f5faf3"

16. material-design-icons-iconfont 包和 eslint 包有冲突，安装了 eslint 后 material-design-icons-iconfont 就被删除了，需要重新安装一次。

17. eslint 检查.vue 文件

• 安装 eslint-plugin-vue
• 在.eslintrc.js 里加上 plugin
• 在 lint 里加上 --ext .js,.vue

plugins: ['vue']
eslint ./src --fix --ext .js,.vue

18. vue-cli3 创建的项目，将 static 文件夹移除了，静态文件可以放到 public 文件夹，可以直接用 localhost:8080/xxx.json 访问

19. 用 ts 的时候也不是说所有的变量都要加类型限制，只需要在自定义的变量，多方调用的地方加，而第三方的类型，如果有类型声明可以加，不加影响也不大。

20. $emit 加自定义参数

$emit 加自定义参数

21. renderless component

renderless component
探索 Vue 高阶组件

22. eslint 检查以下代码报错解决方法

{path: '/login', name: 'Login', component: () => import('@/views/login/Login'), hidden: false }

解决方法，在.eslintrc.js 里添加以下代码，并安装该插件

parserOptions: {parser: "babel-eslint"}

npm install babel-eslint --save-dev

23. iview 里 validate 找不到该属性的 ts 报错解决办法

import {Form} from 'iview'
// iview 里有比较全的 ts 类型定义，可以用起来
type IForm = Form

(this.$refs.form as IForm).validate((valid: boolean | undefined): void => {if (valid) {this.$Message.success('Success!');
    const resp = login({username: '', password:''})
  }
})

stackoverflow 参考

24. pont-engine 配合 swagger

pont-engine

25. npm 安装包的时候如果指定包的依赖版本使用~ 而不使用 ^?

链接

npm install xx -E

26. this.$refs.xxx.$el TS 报错的问题

this.$refs.xxx as Vue).$el