[譯] React 組件的 8 個關鍵決策

• 原文地址：8 Key React Component Decisions: Standardize your React development with these key decisions
• 原文做者：Cory House
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：undead25
• 校對者：Tina92、vuuihc

React 組件的 8 個關鍵決策

經過這些關鍵決策來標準化你的 React 開發

選擇困難症

React 自 2013 年被開源以來，一直在迭代更新。當你在網上搜索相關信息時，可能會被一些使用了過期的方法的文章坑到。因此，如今在寫 React 組件時，你的團隊須要做出如下八個關鍵決策。

決策 1：開發環境

在編寫第一個組件以前，你的團隊須要就開發環境達成一致。太多選擇了……

固然，你能夠從頭開始構建 JS 開發環境，有 25% 的 React 開發者是這麼作的。我目前的團隊使用的是 create-react-app 的 fork，並拓展了一些功能，例如支持 CRUD 的 mock API、可複用的組件庫和加強的代碼檢測功能（咱們會檢測 create-react-app 忽略了的測試文件）。我是喜歡 create-react-app 的，但這個工具能夠幫助你比較許多不錯的替代方案。想在服務端進行渲染？能夠了解下 Gatsby 或者 Next.js。你甚至能夠考慮使用在線編輯器，例如 CodeSandbox。

決策 2：類型檢測

你能夠忽略類型，也可使用 prop-types、Flow 或者 TypeScript。須要注意的是，在 React 15.5 中，prop-types 被提取到了單獨的庫，所以按照較老的文章進行導入會報警告（React 16 會報錯）。

社區在這個話題上依然存在着分歧：

我更傾向於 prop-types，由於我發現它在 React 組件中提供了足夠的類型安全性，幾乎沒有任何阻礙。使用 Babel、Jest、ESLint 和 prop-types 的組合，我不多看到運行時的類型問題。

決策 3：createClass 和 ES 類

React.createClass 是原始 API，但在 15.5 中已被棄用。有點感受咱們將槍頭指向了 ES 類。無論怎樣，createClass 已經從 React 的核心中移除，並被歸類到 React 官方文檔中一個名爲「React without ES6」的頁面。因此很清楚的是：ES 類是趨勢。你可使用 react-codemod 輕鬆地從 createClass 轉換爲 ES 類。

決策 4：類和函數

你能夠經過類或函數來聲明 React 組件。當你須要 refs 或者生命週期方法時，類頗有用。這裏有儘量考慮使用函數的 9 個理由。但值得注意的是，函數組件有一些缺點。

決策 5：狀態

使用普通的 React 組件狀態足以知足大多數場景。狀態提高能夠很好地解決狀態共享的問題。或者，你也可使用 Redux 或 MobX：

我是 Redux 的粉絲，但我常用普通的 React 狀態，由於它更簡單。就目前來看，咱們已經上線了十幾個 React 應用程序，其中的兩個是值得使用 Redux 的。我更喜歡多個小型的、自治的應用程序而不是單個的大型的應用程序。

若是你對不可變狀態感興趣，這裏有一篇相關的文章，提到了至少有 4 種方式來保持狀態不可變。

決策 6：綁定

在 React 組件中，至少有半打方式能夠處理綁定。這主要是由於現代 JS 提供了不少方法來處理綁定。你能夠在構造函數中綁定，在 render 中綁定，在 render 中使用箭頭函數，使用類屬性或者裝飾器。這篇文章的評論裏有更多的選擇！每種方式都有其優勢，但假設你以爲實驗性功能還不錯，我建議默認使用類屬性（也叫屬性初始值）。

這個投票是從 2016 年 8 月開始的。從那時起，類屬性愈來愈受歡迎，而 createClass 的歡迎程度則逐步下降。

附註：許多人對於爲何在 render 中使用箭頭函數和綁定可能存在問題而感到困惑。真正的緣由是由於它使 shouldComponentUpdate 和 PureComponent 變得古怪。

決策 7：樣式

這裏的選擇變得很是多，有 50 多種方式來寫組件的樣式，包括 React 的內聯樣式、傳統的 CSS、Sass/Less、CSS Modules 和 56 個 CSS-in-JS 選項。不開玩笑，我在這個樣式模塊化課程中詳細探索了 React 的樣式，下面是總結：

紅色表明不支持，綠色表明支持，灰色表明警告。

看看爲何在 React 的樣式選擇中有這麼多的分歧？沒有明確的贏家。

看起來 CSS-in-JS 正在蒸蒸日上，而 CSS modules 正在每況愈下。

我目前的團隊使用 Sass 和 BEM，並樂在其中，但我也喜歡樣式組件。

決策 8：邏輯複用

React 最初採用 mixins 做爲組件之間共享代碼的機制。可是 mixins 有問題，如今被認爲是有害的。你不能在 ES 類組件中使用 mixins，因此如今咱們使用高階組件和渲染屬性（也叫子函數）在組件之間共享代碼。

高階組件目前更受歡迎，但我更喜歡渲染屬性，由於它們一般更易於閱讀和建立。

YouTube 視頻

其餘決策

還有一些其餘的決策：

• 你使用 .js 仍是 .jsx 拓展名?
• 你會將每一個組件放在其本身的文件夾中嗎？
• 你會要求每一個組件即一個文件嗎？你會在每一個目錄寫一個 index.js 文件來讓別人感到抓狂嗎？
• 若是使用 propTypes，你會在底部聲明它們，仍是在其自身的類裏使用靜態屬性？你會儘量深地聲明 propTypes 嗎？
• 你會傳統地在構造函數中初始化狀態，仍是使用屬性初始化語法？

因爲 React 大可能是 JavaScript，因此你須要進行許多 JS 開發風格的決策，例如分號、尾隨逗號、格式化以及事件處理的命名。

選擇一個標準，而後自動化執行

全部的這一切，今天你可能會看到不少組合。

因此，下面這幾步是關鍵：

1. 和你的團隊討論這些決策並把大家的標準寫成文檔。

2. 不要浪費時間在代碼審查中手動檢查不一致。要求你的團隊都使用像 ESLint、eslint-plugin-react 和 prettier 這些工具。

3. 須要重構現有的 React 組件？使用 react-codemod 來自動化該過程。

若是我忽略了其它的關鍵決策，請在評論中提出。

想了解更多關於 React 的信息？⚛️

我在 Pluralsight（免費試用）上寫了不少 React 和 JavaScript 課程。

---

Cory House 是 Pluralsight 上許多 JavaScript、React、代碼整潔之道和 .NET 課程的做者。他是 reactjsconsulting.com 的首席顧問、VinSolutions 的軟件架構師、Microsoft 的最有價值專家，而且在國際上培訓軟件開發人員的軟件實踐，例如前端開發和代碼整潔之道。Cory 在 Twitter 上 @housecor 發佈了不少關於 JavaScript 和前端開發的推文。

---

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、React、前端、後端、產品、設計 等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。