使用React一年的簡單總結(jié)！【React系列01】

從2017年9月開始我轉(zhuǎn)為前端開發(fā)，當(dāng)時公司沒有一個單純專注前端的開發(fā)人員，我接到任務(wù)后首先是考慮的是應(yīng)該使用哪種前端技術(shù)（框架）。

在簡單對比Angular、Vue 和 React 后，我選擇了 React。因?yàn)槲以?jīng)花了時間了解過，而且我特別喜歡 React 的 JSX 語法和單向數(shù)據(jù)流綁定方式。本文就簡單總結(jié)一下這一年我使用 React 的實(shí)際經(jīng)驗(yàn)。

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

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

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

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改變給我們?nèi)粘ｉ_發(fā)帶來的影響。

4、 除了上面列出變化，還有 Fragment、異步渲染等等的改變與變化。在短短一年，React 的變化與改進(jìn)很大，這也要我們開發(fā)者需要時刻關(guān)注 React 的動態(tài)，養(yǎng)成習(xí)慣去 React官網(wǎng)查看每個版本的變化日志，這樣才有助于改進(jìn)我們的應(yīng)用，能更好的掌握 React。

二、掌握Babel 和Webpack的配置

1、Babel 總結(jié)

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

因?yàn)?我們的項(xiàng)目基本是運(yùn)行在瀏覽器上的，每個瀏覽器的 JS 支持情況不一致，當(dāng)使用Babel把我們的項(xiàng)目代碼轉(zhuǎn)譯成 ES5，可以最大程度兼容目標(biāo)瀏覽器列表。

在2017年，Babel的 presets 需要我們手動引入所需要的包，如：babel-preset-latest、babel-preset-react、babel-preset-es2015和babel-preset-stage-0。很多時候我們很難確定我們具體需要哪個包，因?yàn)椴恢覀儠陧?xiàng)目中使用什么新特性。

babel-preset-env的出現(xiàn)改變這一現(xiàn)象，可以根據(jù)我們設(shè)置的瀏覽器列表，按需選擇語法環(huán)境包。尤其現(xiàn)在 Babel7的發(fā)布，使得 Babel 配置更加簡單了。

2、Webpack 總結(jié)

Wepack是工程化前端開發(fā)的基礎(chǔ)。我創(chuàng)建第一個React SPA 項(xiàng)目的時候，沒有使用 CRA(create-react-app),因?yàn)槲耶?dāng)時覺得，既然我剛接觸現(xiàn)代前端開發(fā)方式，我就要從零開始學(xué)習(xí)，那當(dāng)然是從 Webpack 配置開始學(xué)習(xí)了。

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

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

三、代碼拆分

1、 React組件拆分

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

2、邏輯函數(shù)拆分

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

3、常量配置的拆分

我們做 SPA，接口作為最大的常量配置項(xiàng)，我們必須用單獨(dú)的文件來聲明這些接口，因?yàn)椴豢赡芤粋€接口只用在一個地方，當(dāng)接口路徑改變時，我們只需要在接口聲明文件中更改一次即可。而且不能模塊的接口需要拆分到不同的文件中，增加可讀性。還有其他的一些頁面配置聲明都可以放到統(tǒng)一目錄下（constants目錄），這樣不僅讓項(xiàng)目結(jié)構(gòu)更加清晰，而且增加代碼的健壯性。

四、不斷的重構(gòu)、重構(gòu)

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

在我的項(xiàng)目中，我重構(gòu)最多的是應(yīng)用的路由，從開始只是使用頁面級別的路由，到現(xiàn)在每個組件都使用路由，其中重構(gòu)的次數(shù)不下與10次。

也許我一開始就應(yīng)該考慮這種路由方式了，但當(dāng)時是一個簡單的項(xiàng)目就沒必要搞那么復(fù)雜吧。并不是我不想這樣做，只是必要性太低了。其實(shí)重構(gòu)的過程，也是對代碼進(jìn)行改進(jìn)的過程，隨著開發(fā)時間的增加，對代碼使用的理解不一樣了，重構(gòu)讓我更升入理解了 React 的一些 API。只要我有空， 我就會 review 項(xiàng)目的代碼，看看哪些地方可以改進(jìn)，包括 Babel Webpack 配置的重構(gòu)。

五、代碼規(guī)范和團(tuán)隊(duì)協(xié)作

一個好的項(xiàng)目不只是說功能完成了就可以了，除了不斷重構(gòu)之外，在每次的編碼過程中注意編碼規(guī)范還是十分重要的。

因?yàn)榇a是寫給人看的，自己看的懂的代碼，團(tuán)隊(duì)成員不一定能看懂。除了代碼需要格式化之外，還需要一定的注釋，在邏輯復(fù)雜的地方增加一定的注釋，方便團(tuán)隊(duì)成員和日后自己的 review 代碼時能看懂該段代碼，也會對優(yōu)化帶來啟示的。

在 Rect 這樣的前端項(xiàng)目中，一般使用 ESLint 進(jìn)行語法規(guī)范、用Prettirer進(jìn)行代碼美化，而且還要對編輯器進(jìn)行美化編寫規(guī)則，如.editorconfig,讓團(tuán)隊(duì)成員的在其編輯器上寫出的代碼與自己的風(fēng)格一致。

六、嘗試使用高級特性

在項(xiàng)目開發(fā)開始階段中，我們因?yàn)閷Ｗ⒂跇I(yè)務(wù)功能的實(shí)現(xiàn)，容易忽略一些功能其實(shí)可以用高級特性來實(shí)現(xiàn)。這就讓我們在重構(gòu)的過程中考慮是否使用高級特性來替代當(dāng)前的實(shí)現(xiàn)邏輯了。使用高級特性不僅讓我們的項(xiàng)目代碼簡潔、還可以讓我更好的理解React、JS 的高級特性，這樣的項(xiàng)目開發(fā)方式才能最大程度提升自己的水平。

七、使用 TypeScript吧

由于項(xiàng)目開始時，我對 TypeScript 一無所知，壓根沒考慮過使用 TypeScript 來實(shí)現(xiàn)。對應(yīng) TypeScript 的有點(diǎn)和在 React 的使用方式，我在前面的文章有寫過。現(xiàn)在我最苦惱的是，我很想使用 TypeScript 來開發(fā)，但把現(xiàn)在的項(xiàng)目代碼轉(zhuǎn)為 TypeScript 的工作量實(shí)在太大了。因此，我們應(yīng)盡可能在項(xiàng)目使用 TypeScript!!!

八、解決困難的能力

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

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

關(guān)注公眾號，置頂公眾號,鬼哥,一起前端進(jìn)階

點(diǎn)擊關(guān)注我們↓