抉擇系列：在技術(shù)開發(fā)的過程中我們會面臨著各種各樣的抉擇，我們在不同情境下該如何選擇恰當(dāng)?shù)募夹g(shù)，這是本系列文章想要解決的問題。

在 React 開發(fā)的過程中我們常常會遇到一些抉擇，下面我將選取其中一些個人認(rèn)為重要的抉擇來一一分析。但請記住以下所說的都只是的建議，可能有一些方面也沒有考慮到，大家還是需要依據(jù)實際情況自己選擇最合適的，切勿隨波逐流。

抉擇 1：開發(fā)環(huán)境搭建

當(dāng)開始React開發(fā)之前，你或你的團(tuán)隊必須先考慮選擇什么樣的開發(fā)環(huán)境，先愉快的呈上群眾的選擇圖。

通用場景建議使用 create-react-app，它將滿足你大部分的開發(fā)需求。如果默認(rèn)配置不能滿足你的需求，運(yùn)行 npm run eject 按需修改你的配置吧(溫馨提示：此過程式不可回退的)。

其他可替代

• Gatsby 適用于開發(fā)靜態(tài)網(wǎng)站
• Next.js 適用于前后端同構(gòu)方案

如果以上皆不能滿足你的需求時，親，自己動手，豐衣足食。

抉擇 2：類型

JavaScript 是弱類型語言，你可能忽視類型檢查，也可能需要引入類型檢查。下圖是群眾的選擇圖，你將如何選擇?

如果你懶得折騰，那 prop-types 可以滿足你的類型驗證，也會避免大部分的類型問題。

如果你喜歡折騰，追求完美，沒有問題還有下面兩種選擇：

• TypeScript JavaScript 的超集，最終可編譯成清晰與整潔的原生JavaScript代碼.
• Flow 為 Javascript 添加靜態(tài)類型檢查，用于提高開發(fā)者的效率與代碼質(zhì)量。

抉擇 3：ES5(createClass) VS ES6(class)

如果你開發(fā)環(huán)境使用的是ES5語法，那你沒得選擇只能使用createCalss，推薦官方文章《非ES6環(huán)境下如何使用React》

如果你開發(fā)環(huán)境使用ES6語法，強(qiáng)烈建議使用 class，使用起來更簡單，F(xiàn)acebook 也推薦使用 Class，示例代碼如下：

class SayHello extends React.Component { 
   constructor(props) { 
     super(props); 
     this.state = {message: 'Hello!'}; 
   } 
   render() { 
     return ( 
       <p> 
         Say: {this.state.message} 
       </p> 
     ); 
   } 
 }  

抉擇 4：類 VS 純函數(shù)

如果你不需要使用生命周期，盡可能使用無狀態(tài)純函數(shù)(Stateless functional components：react-v0.14版本添加的新特性)。

無狀態(tài)純函數(shù)簡單例子：

// 無狀態(tài)純函數(shù)組件，使用 ES5  
  var Aquarium = function(props) { 
    var fish = getFish(props.species); 
    return <Tank>{fish}</Tank>; 
  }; 
 
  // 無狀態(tài)純函數(shù)組件，使用 ES2015 (ES6) 箭頭函數(shù): 
  var Aquarium = (props) => { 
    var fish = getFish(props.species); 
    return <Tank>{fish}</Tank>; 
  }; 
 
  // 或者再使用對象解構(gòu)與默認(rèn)的返回，簡單： 
  var Aquarium = ({species}) => ( 
    <Tank> 
      {getFish(species)} 
    </Tank> 
  ); 
 
  // 然后使用: <Aquarium species="rainbowfish" />  

依據(jù)單一職責(zé)原則，你的組件應(yīng)該只有且只一個職責(zé)，內(nèi)部的邏輯盡量設(shè)計扁平。如果邏輯復(fù)雜，那你要問自己組件是否還需要分解，使用純函數(shù)會使你時時刻刻考慮組件的設(shè)計是否合理。

總之一句話，純函數(shù)能幫你更好的設(shè)計的你組件，底層的原子組件盡量使用純函數(shù)，可復(fù)用或者更復(fù)雜的邏輯可以考慮抽離出高價邏輯組件。

也并不是說所有地方都要使用純函數(shù)，如果你的組件確實需要狀態(tài)與生命周期相關(guān)操作，那就使用類。

附帶兩篇同一個作者的不同觀點的文章(英文)：

• 使用無狀態(tài)函數(shù)組件的9個理由 React Stateless Functional Components: Nine Wins You Might Have Overlooked
• 7個不使用無狀態(tài)純函數(shù)組件的理由 7 Reasons to Outlaw React’s Functional Components

抉擇 5：State

接下來你要考慮的是如何管理你的狀態(tài)數(shù)據(jù)，業(yè)界已經(jīng)有很多方案，群眾的選擇是

如果是簡單WEB的應(yīng)用，可能 React 提供的 setState() 就完全能滿足你的需求，夠用就好別強(qiáng)行加入其它 State 管理框架。

如果是大型的WEB應(yīng)用，個人建議使用 Redux。Redux是JavaScript應(yīng)用程序的可預(yù)測狀態(tài)管理容器。它可以幫助您編寫行為一致的應(yīng)用程序，可在不同環(huán)境(WEB客戶端，服務(wù)器和手機(jī)應(yīng)用等)中運(yùn)行，并且易于測試。

順便提一下Redux借鑒的其核心思想之一的框架 Flux，有興趣可以是研究一下。

Bobx，簡單，可擴(kuò)展的狀態(tài)管理庫。本人也沒有使用就不細(xì)說了

抉擇 6：綁定(Binding)

一張圖能搞定，就不多做解釋了

使用箭頭函數(shù)綁定示例代碼如下：

class SayHello extends React.Component { 
   constructor(props) { 
     super(props); 
     this.state = {message: 'Hello!'}; 
   } 
 
   // 使用箭頭函數(shù)banding 
   handleClick = () => { 
     alert(this.state.message); 
   } 
 
   render() { 
     return ( 
       <button onClick={this.handleClick}> 
         Say hello 
       </button> 
     ); 
   } 
 }  

使用構(gòu)造函數(shù)中綁定示例代碼如下：

class SayHello extends React.Component { 
    constructor(props) { 
      super(props); 
      this.state = {message: 'Hello!'}; 
       
      // 在用構(gòu)造函數(shù)banding 
      this.handleClick = this.handleClick.bind(this); 
    } 
 
    handleClick() { 
      alert(this.state.message); 
    } 
 
    render() { 
      return ( 
        <button onClick={this.handleClick}> 
          Say hello 
        </button> 
      ); 
    } 
  }  

抉擇 7：樣式(Styling)

樣式的選擇太多了，我們就不一一列舉，我們選擇幾個React開發(fā)者常用的選擇項，群眾的選擇盡在下圖中

依據(jù)群眾的選擇，好像(由于上圖群眾的人數(shù)不詳，樣本不能足，只能說好像) CSS-in-JS 正在吞噬 CSS-Modules 的份額。

Cory House 的選擇編寫代碼使用SASS，命名使用BEM已經(jīng)足夠，他也關(guān)注 styled-components。

本人傾向邏輯，結(jié)構(gòu)與樣式分離，現(xiàn)階段還是使用SASS，命名使用BEM。近期在探討更適合自己的樣式CSS組織架與命名方式，后續(xù)會有專門的文章(《CSS架構(gòu)解決方案系列》)，本文就不做深入研究了。

下面簡單的羅列一下，如何更好的組織樣式的解決方案： OOCSS, SMACSS, BEM, ITCSS, ECSS, SUIT CSS, Atomic Design, Atomic。歡迎補(bǔ)充!

抉擇 8：復(fù)用邏輯

接下來你要面對的是如何復(fù)用你的邏輯，編程世界的一句名言“不要重復(fù)自己”。默默的看著群眾的選擇圖

React 最初是使用Mixins，但是使用 mixins會導(dǎo)致一些BUG與被認(rèn)為是有害的(Mixins Considered Harmful)。

高階組件(Heigher Order Components), 如果不了解可以閱讀下列文章：

• Facebook官方文檔英文 Higher-Order Components
• 中文閱讀 深入理解 React 高階組件

高級組件時現(xiàn)在最流行的方案，但還是需要了解 render props，它比高級組件跟容易閱讀與創(chuàng)建。其實我還沒有深入理解與實踐 render props，無法給出建議，看你自己的選擇。

我現(xiàn)在使用的是高級組件，未來也不排除會使用 render props，軟件行業(yè)不不變的主題就是“變化”，說不定還會有更合理的方案呢?

抉擇 9：目錄結(jié)構(gòu)

你是喜歡所有組件共用一個文件夾呢，如下

src/ 
  |- App.js 
  |- RewarmView.js 
  |- RewarmSearchInput.js 
  |- RewarmImage.js 
  |- RewarmLoading.js 
  |- RewarmError.js 
  |- giphyLoadData.js  

還是每個組件有自己的文件夾，基本結(jié)構(gòu)如下

src/ 
  |- App.js 
  |- RewarmSearch/ 
      |- index.js 
      |- View.js 
      |- SearchInput.js 
      |- Image.js 
      |- Loading.js 
      |- Error.js 
      |- loadData.js  

收起文件夾，看起來是不是很整潔

src/ 
  |- App.js 
  |- RewarmSearch/  

每個組件在其單獨的文件夾，更詳細(xì)可閱讀

• Writing Scalable React Apps with the Component Folder Pattern
• The 100% correct way to structure a React app (or why there’s no such thing

個人推薦的是每個組件擁有自己的文件夾，你呢?

說在最后

本人雖然有6年前端的開發(fā)經(jīng)驗，但文章難免會有遺漏，也可能與你的想法是對立的，歡迎大家提出建議或說出你不一樣的觀點。

參考文獻(xiàn)

《 8 key React Component Decisions 》 (本鏈接需要翻墻)