使用 React 一年的簡單總結

從 2017 年 9 月開始我轉爲前端開發，當時公司沒有一個單純專注前端的開發人員，我接到任務後首先是考慮的是應該使用哪種前端技術（框架）。

在簡單對比 Angular、Vue 和 React 後，我選擇了 React。因爲我曾經花了時間瞭解過，而且我特別喜歡 React 的 JSX 語法和單向數據流綁定方式。本文就簡單總結一下這一年我使用 React 的實際經驗。

我開始使用 React 時的版本是 16.0.0，到現在 16.5.0，我感受到最大的變化是：

1、新增了 Context，翻譯爲：上下文。有了這個 API 我們可以簡單的共享組件間的數據。比如：在向多級子組件傳 props 時無需每一級組件都要傳遞 props。在頂級組件創建了 Context.Provider, 在任何子組件中使用 Context.Consumer 就可以獲取到頂級組件的 props。

2、多種 ref 的創建方式。在最初，要訪問 DOM ，需要在組件增加 ref={myRef}，而且 ref 的值只能是 string。到現在，我們不僅可以利用原來的方式創建（舊不被官方推薦），還可以 ref={ins => this.myRef = ins} ，ref 的值可以是一個函數；當然還可以這樣:

class  extends React.Component {
  constructor(props) {
    super(props);
    this.myRef = React.createRef();
  }
  render() {
    return <div ref={this.myRef} />;
  }

3、在 16.3.0 版本中，React 組件的生命週期增加了 static getDerivedStateFromProps(),getSnapshotBeforeUpdate(),componentDidCatch(), 並且對componentWillReceiveProps()和componentWillUpdate()增加了不安全的前綴，如：UNSAFE_componentWillReceiveProps()。

我們這裏不展開討論這些生命週期 API 改變給我們日常開發帶來的影響。

4、除了上面列出變化，還有 Fragment、異步渲染等等的改變與變化。在短短一年，React 的變化與改進很大，這也要我們開發者需要時刻關注 React 的動態，養成習慣去 React 官網查看每個版本的變化日誌，這樣纔有助於改進我們的應用，能更好的掌握 React。

二、掌握 Babel 和 Webpack 的配置

1、Babel 總結

Babel 是現代化前端開發的關鍵角色，Babel 的存在才使得我們可以用 ES6、ES7，甚至 ES8 的新特性來開發前端項目。

因爲我們的項目基本是運行在瀏覽器上的，每個瀏覽器的 JS 支持情況不一致，當使用 Babel 把我們的項目代碼轉譯成 ES5，可以最大程度兼容目標瀏覽器列表。

在 2017 年，Babel 的 presets 需要我們手動引入所需要的包，如：babel-preset-latest、babel-preset-react、babel-preset-es2015 和 babel-preset-stage-0。很多時候我們很難確定我們具體需要哪個包，因爲不知我們會在項目中使用什麼新特性。

babel-preset-env 的出現改變這一現象，可以根據我們設置的瀏覽器列表，按需選擇語法環境包。尤其現在 Babel7 的發佈，使得 Babel 配置更加簡單了。

2、Webpack 總結

Wepack 是工程化前端開發的基礎。我創建第一個 React SPA 項目的時候，沒有使用 CRA(create-react-app), 因爲我當時覺得，既然我剛接觸現代前端開發方式，我就要從零開始學習，那當然是從 Webpack 配置開始學習了。

Webpack 作爲現在最流行的打包工具，但由於其鬆散的配置方式和插件化配置使得整個 Webpack 配置讓人看起來十分複雜，因此讓很多人望而卻步，不敢真正去了解 Webpack 配置項的意義。其實，Webpack 配置沒那麼難，尤其現在 Webpack4 的出現，可以說可以是零配置了。在項目開始的時候，只需要配置入口，出口、css 加載器和 js 加載器就可以項目運行起來了。至於其他的配置，用到的時候再添加也不遲。

配置優化更加不能急，項目的完成度沒有到達 90%，談優化是多餘的。這一年來，我項目中 Webpack 配置不知改了多少次了，這種東西並不是說開始配置好了就不用再改動了。所以我們一步一步來，就可以慢慢熟悉整個 Webpack 配置的訣竅了。

三、代碼拆分

1、 React 組件拆分

我特別喜歡 React 的組件化開發，在開發過程中我們可以重用組件。當一個頁面的功能增多時，代碼數肯定飆升的。這個時候我們可以考慮把一些功能拆分出來，不僅使得當前文件代碼減少，增加可讀性，而且說不定當前拆分的小功能組件可以被其他頁面重用，減少重複的工作量。不用害怕拆分，哪怕是一個按鈕都可以抽取到一個獨立的組件中，比如：在我的項目中，我的一個小小的刪除按鈕就拆分出來，因爲每個刪除按鈕都需要一個彈窗按鈕來包裹，每次寫按鈕功能時，都要重複的用彈窗組件來包裹，拆分一個自定義的刪除按鈕就讓我們每次只需要引用我們的資金的刪除按鈕即可。當然，組件的拆分可以拆分成無狀態組件、正常功能組件，甚至是自定義業務組件庫。我在前面的文章寫過自建公司內部的 React 業務組件庫，因爲這些組件不只是可以在當前項目使用，多個項目實行相同的功能時，不斷的 copy 也是增加工作量。

2、邏輯函數拆分

我們都知道一個函數方法只實現一種功能，一般來說每個頁面都是特定的功能，但總會存在相同的數據處理方式。這個時候我們創建一個函數庫，把常用的數據處理方法抽取出來，在別的頁面使用時就可以簡單實現了。比如：在判斷值是否有效時，雖然是很簡單的方法，但每次都要這樣判斷 null、undefined 以及 (空串), 着實讓人感覺麻煩。

3、常量配置的拆分

我們做 SPA，接口作爲最大的常量配置項，我們必須用單獨的文件來聲明這些接口，因爲不可能一個接口只用在一個地方，當接口路徑改變時，我們只需要在接口聲明文件中更改一次即可。而且不能模塊的接口需要拆分到不同的文件中，增加可讀性。還有其他的一些頁面配置聲明都可以放到統一目錄下（constants 目錄），這樣不僅讓項目結構更加清晰，而且增加代碼的健壯性。

四、不斷的重構、重構

這一年來，項目功能在不斷變化，這樣也帶來項目代碼頁不斷變化，出來不斷拆分代碼之外。我們要不斷的對每個功能的實現方式不斷重構，也行以前需要用 10 行代碼才能解決的問題，現在想到了一個更好的方法，只需要 5 行了。

在我的項目中，我重構最多的是應用的路由，從開始只是使用頁面級別的路由，到現在每個組件都使用路由，其中重構的次數不下與 10 次。

也許我一開始就應該考慮這種路由方式了，但當時是一個簡單的項目就沒必要搞那麼複雜吧。並不是我不想這樣做，只是必要性太低了。其實重構的過程，也是對代碼進行改進的過程，隨着開發時間的增加，對代碼使用的理解不一樣了，重構讓我更升入理解了 React 的一些 API。只要我有空，我就會 review 項目的代碼，看看哪些地方可以改進，包括 Babel Webpack 配置的重構。

五、代碼規範和團隊協作

一個好的項目不只是說功能完成了就可以了，除了不斷重構之外，在每次的編碼過程中注意編碼規範還是十分重要的。

因爲代碼是寫給人看的，自己看的懂的代碼，團隊成員不一定能看懂。除了代碼需要格式化之外，還需要一定的註釋，在邏輯複雜的地方增加一定的註釋，方便團隊成員和日後自己的 review 代碼時能看懂該段代碼，也會對優化帶來啓示的。

在 Rect 這樣的前端項目中，一般使用 ESLint 進行語法規範、用 Prettirer 進行代碼美化，而且還要對編輯器進行美化編寫規則，如. editorconfig, 讓團隊成員的在其編輯器上寫出的代碼與自己的風格一致。

六、嘗試使用高級特性

在項目開發開始階段中，我們因爲專注於業務功能的實現，容易忽略一些功能其實可以用高級特性來實現。這就讓我們在重構的過程中考慮是否使用高級特性來替代當前的實現邏輯了。使用高級特性不僅讓我們的項目代碼簡潔、還可以讓我更好的理解 React、JS 的高級特性，這樣的項目開發方式才能最大程度提升自己的水平。

七、使用 TypeScript 吧

由於項目開始時，我對 TypeScript 一無所知，壓根沒考慮過使用 TypeScript 來實現。對應 TypeScript 的有點和在 React 的使用方式，我在前面的文章有寫過。現在我最苦惱的是，我很想使用 TypeScript 來開發，但把現在的項目代碼轉爲 TypeScript 的工作量實在太大了。因此，我們應儘可能在項目使用 TypeScript!!!

八、解決困難的能力

我覺得開發是一件很快樂的事情，開發過程遇到困難首先嚐試自己解決，才能提升自己；也不要吝嗇幫助別人，也許別人遇到的問題正是自己前不久剛解決的，這樣能加深印象。希望能幫到大家。

原文地址: https://www.dazhuanlan.com/2020/01/20/5e2506b1355ba/

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/-wmEkNAvaXo6lZfOi1AlIA