抉擇系列：在技術開發的過程中我們會面臨著各種各樣的抉擇，我們在不同情境下該如何選擇恰當的技術，這是本系列文章想要解決的問題。

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

抉擇 1：開發環境搭建

當開始React開發之前，你或你的團隊必須先考慮選擇什么樣的開發環境，先愉快的呈上群眾的選擇圖。

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

其他可替代

• Gatsby 適用于開發靜態網站
• Next.js 適用于前后端同構方案

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

抉擇 2：類型

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

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

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

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

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

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

如果你開發環境使用ES6語法，強烈建議使用 class，使用起來更簡單，Facebook 也推薦使用 Class，示例代碼如下：

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

抉擇 4：類 VS 純函數

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

無狀態純函數簡單例子：

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

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

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

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

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

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

抉擇 5：State

接下來你要考慮的是如何管理你的狀態數據，業界已經有很多方案，群眾的選擇是

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

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

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

Bobx，簡單，可擴展的狀態管理庫。本人也沒有使用就不細說了

抉擇 6：綁定(Binding)

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

使用箭頭函數綁定示例代碼如下：

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

使用構造函數中綁定示例代碼如下：

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

抉擇 7：樣式(Styling)

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

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

Cory House 的選擇編寫代碼使用SASS，命名使用BEM已經足夠，他也關注 styled-components。

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

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

抉擇 8：復用邏輯

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

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

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

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

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

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

抉擇 9：目錄結構

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

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

還是每個組件有自己的文件夾，基本結構如下

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

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

src/ 
  |- App.js 
  |- RewarmSearch/  

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

• 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年前端的開發經驗，但文章難免會有遺漏，也可能與你的想法是對立的，歡迎大家提出建議或說出你不一樣的觀點。

參考文獻

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