Flow

Flow的意義

Flow是faceBook開源的一個JavaScript靜態型別檢查工具，作用類似TypeScript，但是它不像TS那樣是一門獨立的語言，而是作為一個babel-plugin,藉助babel的編譯切入JavaScript的編碼當中，同時，與ts不同的是，Flow.js的型別檢查不是強制的，可以通過//@flow手動開啟，意味著，你可以自由選擇某個檔案是否開啟型別檢查。   Flow真是眼前一亮，我就想，TypeScript挺好的，但或許也給人帶來了一些煩惱，一旦用了TS，就意味著任何時候都要強制型別檢查，我覺得，選擇JavaScript還是TypeScript就變成了這樣一個問題：我們手頭1000元，我們到底是買一件一萬元的比較喜歡的還耐用的衣服呢？還是買一件很便宜但是又不耐用的地攤貨呢？（耐用指的是維護性），但Flow幫我們找到了折中方案：型別檢查這東西，我們在想用和需要用的時候用，同時不想用也可以不用，就好比就是手裡有1000塊，那我們就剛好去買1000塊錢的衣服

Flow的使用

//@flow
//數字
functionflow1(x:number){
  console.log(x);
}
flow1(2);
//字串
functionflow2(x:string){
  console.log(x);
}
flow2("xxx");
//可選引數
functionflow3(x:?string){
  console.log(x);
}
flow3();
//多個值
functionflow4(x:"a"|"b"|"c"){
  console.log(x);
}
flow3("a");
//任意值
functionflow5(y:any){
  console.log(y);
}
flow3("a");
//陣列
let arr:Array<boolean>=[true,false,true];

 

Flow的優點

• 自由和[可選]的型別檢查風格
• 輕量化的型別檢查，滿足一些基本要求，同時容易學習上手
• 藉助babel，webpack整合到JS程式碼中，在當今前端社群中，這種方式非常容易被大家所理解和接受，同時也容易整合到已有的專案中

Flow的缺點

這傢伙簡直和JS一毛一樣，既有有好用的優點，同時呢，卻也有一些明顯的缺點。

• 編輯器或IDE整合度低,比如，比如基本的變數提示功能
• 社群力量較弱，庫的數量較少
• 庫的型別定義質量不高，無法完全滿足開發需求
• FacebookFlow團隊的roadmap也並不是很清楚

Flow的安裝（Webpack整合）

(注意⚠️：你需要確保你有一個可執行的webpack配置，同時在module.rules配置項中引入了babel-loader解析所有js檔案)

過程

1. 下載VScode擴充套件外掛：FlowLanguageSupport，以在IDE中支援
2. 安裝plugin-transform-flow-strip-types外掛，執行以下命令

npm install @babel/plugin-transform-flow-strip-types

4. 建立.babelrc檔案，寫入以下配置

{
  "plugins":[
    "transform-flow-strip-types"
  ]
}

5. 執行以下命令，安裝flow命令列

npm install -g flow-bin

 

6. 在每次啟動專案前都檢查Flow是否有報錯，例如我就在在啟動指令碼中新增如下語句，它每次會先檢查flow有沒有報錯，然後才用Node啟動專案

"scripts":{
  "start":"flow check src && node ./server.js",
}

7. 編寫flow程式碼吧！！但是你需要給當前檔案加上//@flow，如果不加，那麼flowcheck將不做檢查

//@flow
functionflow1(x:number){
  console.log(x);
}
//flow函式
flow1(2);
//普通函式
functioncommon(a){
  console.log(a);
}
common(1);

 

執行示例

執行 flow check src檢測src下的執行情況   型別匹配，無錯誤 型別不匹配，報錯（要求數字但傳入了字串）    

Prettier

prettier的意思是漂亮的，但其實我覺得，“美化程式碼”並不是它的核心功能，它的核心功能是“統一程式碼規範”（當然了，是用漂亮的規範去統一哈哈）。長久以來，團隊建設的一個重點要求就是”讓幾十個人寫的程式碼看上去是一個人寫的“。倘若如此，團隊協作，程式碼維護能力便大大增強。Prettier是完成這一豐功偉績的功臣。   Prettier是用來規範程式碼風格的，一些IDE比如VScode可以給我們提供程式碼格式化的功能，但是這種功能仍然有限。Prettier則提供了相當完善的程式碼風格規範。   試看—— A：我就喜歡這樣寫！！

import {A,B,C,D,E} from‘lib’

B: 我建議啊，應該這樣寫

import{
  A,
  B,
  C,
  D,
  E
} from ‘lib’

A：你寫的不夠大氣！ B：你寫的不夠簡潔！ (互懟時刻即將開啟）   Prettier和事佬：好了好了，兩位英雄莫相爭執，且聽我的！你們都寫成我這樣就得了！ A,B:好，那咱就這麼辦  

如何使用Prettier

1. 在VScode上下載Prettier擴充套件外掛，最好把編輯器重啟一下。然後儲存時就可以自動格式化了
2. 根據官網上的指示進行操作，下面這個講的是如何從Eslint上整合Prettier Integrating with Linters · Prettier
3. 其實一般情況下，有VScode的Prettier外掛就足夠指導開發了，如果你想一次性把全部JS/JSX檔案全部格式化一遍，可以這樣，在根目錄下執行：

yarn prettier --write './src/**/*.js' './src/**/*.jsx’

 

執行示例

右邊是格式化後的  

ESlint

ESlint這種和我們朝夕相處的夥伴就不必過多解釋了吧，它的作用是做一些靜態檢查，對於一些可能在JS執行時候才會報的錯誤立即檢測出來。

ESlint的使用

1. 在VScode上下載Eslint擴充套件外掛，最好把編輯器重啟一下
2. 設定Eslint這個VScode擴充套件外掛的AutoFix功能，如圖所示
3. 在專案下安裝eslint命令列並進行初始化

  3.1 執行 npm init: 先初始化下npm空間    
  3.2 執行 npm i eslint, 安裝eslint
  3.3 執行 eslint --init：初始化eslint

         當你敲出init後，eslint的命令列會自動詢問你一大堆選擇題，而你只要通過箭頭選擇選項並回車就好了，很方便啊！ 這些問題包括：

• Q1. 你想如何使用eslint?1.檢查語法2.檢查語法並且發現問題3.檢查語法，發現問題並強制約定程式碼風格
• Q2. 你的專案使用的模組化方式？1.CommonJS 2.Import/export 3.None of these
• Q3. 你的環境？ 1.Node 2.瀏覽器
• Q4. 你使用到的框架? 1.React 2.Vue 3. None of these
• Q5. 你的專案使用TypeScript? 1.Y 2.N

(爽！媽媽再也不用擔心我的配置了)   你可能會問：哎呀！我不小心搞錯了選項！，那我要重新來一次嗎？ 不用的，因為其實上面的選擇只是幫助生成配置檔案而已，你要改隨時改配置檔案就可以了呀。   我們來看下面的一份配置檔案

{
  "env":{
    "browser":true,
    "es6":true
  },
  "extends":[
    "eslint:recommended",
    "plugin:@typescript-eslint/eslint-recommended"
  ],
  "globals":{
    "Atomics":"readonly",
    "SharedArrayBuffer":"readonly"
  },
  "parser":"@typescript-eslint/parser",
  "parserOptions":{
    "ecmaVersion":2018,
    "sourceType":"module"
  },
  "plugins":["@typescript-eslint"],
    "rules":{
      "semi":  ["error","always"],
      "quotes":["error","double"]
  }
}

 

eslint真棒，讓我們看看這些配置選項都是怎麼搞的吧 1.env配置項 常見的可配置的有

"env":{
  "browser":true,//瀏覽器環境
  "node":true,//Node環境
  "es6":true,//es6語法
  "commonjs":true,//commonjs
  "worker":true//webwork相關語法
},

2.globals配置項 它配的是全域性變數，一般情況下，按照eslint的規則，直接使用全域性變數是會報錯的，globals配置項幫你避免了這一點

"globals":{
  "Atomics":"readonly",
  "SharedArrayBuffer":"readonly"
},

 

3.parser配置項 可以配置解析器，預設是用的typescript的解析器，比如我們專案中就改成了babel-parser

"parser": "@typescript-eslint/parser”,

 

4.rules 配置具體的檢查細節，比如下面這條配置直接幹了no-console，如果使用console.log會報警告。如圖所示

"rules":{
  "no-console":1
}

每個專案後面可以跟0，1，2三種數字

0:不報錯，不警告
1：警告但不報錯
2:報錯

5.extends 你可能會問了，哎呀！！這麼多rules我還怎麼配啊，這樣eslint配置檔案連起來都可以繞VScode兩圈了！ 不要擔心！！我們有extends配置項這個好東西，它提供的繼承功能直接集成了一些預設的配置，如下

"extends":[
  "eslint:recommended",
  "plugin:@typescript-eslint/eslint-recommended"
]

 

6.plugins 加各種外掛，比如你想增加React的檢查怎麼辦？ 你需要安裝eslint-plugin-react這個外掛 然後在配置中增加以下內容

"plugins":["react”]

就OK了  

執行示例

  備註：官方推薦使用區域性eslint而非全域性eslint

ESLint was installed locally. We recommend using this local copy instead of your globally-installed copy