又是一波前端知識點總結

總結的點都雜七雜八，但願能找到對你有所幫助的，沒有的也沒關係嘛！😄

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[code]~~ // 錯誤的寫法
    let dom = this.$refs[code][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