• 原文地址：When Does a Project Need React?
• 原文作者：CHRIS COYIER
• 譯文出自：掘金翻譯計劃
• 譯者：龍騎將楊影楓
• 校對者：Guangyuan (Charlie) Yang、薛定諤的貓

專案什麼時候需要 React 框架呢？

你知道什麼時候專案需要 HTML 和 CSS，因為這是專案的基礎。什麼時候用 JavaScript 也很清楚：當你需要只有它能提供的互動功能的時候。過去我們什麼時候應該用程式碼庫也很清楚：我們需要 jQuery 來幫助我們簡化 DOM 操作，呼叫 Ajax，處理瀏覽器相容問題；我們需要 Underscore 提供 JavaScript 沒有的幫助函式（ helper functions ）。

但是隨著對這些程式碼庫的需求逐漸消失，我們看到很多新興框架的大幅增長。我認為，就不那麼容易確定何時需要它們了。比如說，我們什麼情況下需要 React 框架？

在眾多的 JavaScript 框架中 —— Vue、Ember、Svelte … 不管哪一個，我想以 React 框架為例子來探討它適合什麼專案。我明白這些框架並不完全相同，但是使用它們的時機應該是有一些共性的。

這是我的建議。

當專案中有大量的狀態的時候

即便“狀態（state）”這個詞也無法完全準確的表達我的意思。想象一下這些情況：

• 導航欄的哪個欄目正處於啟用狀態
• 一個按鈕是否被禁用
• 輸入框的值
• 哪一個下拉框是彈出的狀態
• 何時載入某個區域
• 登陸的使用者如何進行許可權控制
• 使用者編寫的文章是已釋出狀態還是草稿狀態

“業務邏輯” —— 我們經常處理的這類東西。狀態也可能和內容直接相關：

• 一篇文章中所有的評論，以及零零碎碎的組成它們的東西。
• 當前正在檢視的文章，以及該文章的一些屬性
• 一系列相關的文章，以及這些文章的屬性
• 一份作者列表
• 一份記錄使用者近期操作的活動日誌

React 框架並沒有幫助你組織這些狀態，它只是說：我知道你需要處理狀態的問題，所以我們不如把它設為 state 屬性，通過程式設計的方式進行讀寫。

在有 React 框架之前，我們也許考慮過狀態的定義，但是大部分時候並沒有把它當作一個直接的概念去管理。

也許你聽說過這個短語“單一資料來源”？很多時候我們把 DOM 作為我們的單一資料來源。比如說，你需要知道是否可以提交某個表單了。也許你會用 $(".form input[type=`submit`]).is(":disabled") 去檢查一下，因為所有影響表單是否可提交的業務邏輯最終都會改變按鈕的 disable 屬性。所以按鈕變成了你的 app 事實上的資料來源。

或者說，你需要知道某篇文章的第一個評論者的名字，也許你會這樣寫 $(".comments > ul > li:first > h3.comment-author).text()，因為 DOM 是你唯一可以獲得這些資訊的地方。

React 框架這樣告訴我們：

1. 我們把這些所有的東西都想像成狀態（state）。

2. 我會為你做好一件事：把狀態轉換為一串 JSON 物件，這樣的話處理起來很容易，也許你的服務端可以處理的很漂亮。

3. 更棒的是：你可以用這些狀態（state）直接構建 HTML ，你根本不需要直接操作 DOM，我都替你處理了（也許比你親自處理的要更快更好）。

對抗麵條式程式碼 （Spaghetti）

這和我們剛才討論過的狀態有非常大的關係。

“麵條式”程式碼，指的是程式碼的組織結構已經脫離你的掌控。再想象一下，假設有這麼一個表單，它有一些專門處理表單內輸入框的業務邏輯。該表單內有這麼一個數字輸入框，當這個輸入框的值改變的時候，在旁邊顯示根據該值進行某些計算後的結果。這個表單可以被提交至服務端，因此也需要合法性檢查，而也許合法性檢查的程式碼位於其他地方的驗證庫中。也許在確定某處的 JavaScript 程式碼全部載入完之前，你還需要禁用此表單，而這個邏輯也在別的地方。也許當表單提交後，你還需要處理一些返回值。沒有什麼特別讓人意外的功能，但是湊在一起就很容易讓人蒙圈。如果這個專案由一個新的開發人員接手，當他看到這個表單時如何能捋清這些邏輯呢？

React 框架鼓勵把邏輯封裝進元件。所以這個表單要麼自己是一個元件，要麼由其他的小元件組成。每一個元件只處理與自己直接相關的邏輯。

React 框架說：嗯，你不會直接看到 DOM 的變化，因為 DOM 是我的，你無法直接操作它。為什麼你不把這些東西想象成狀態的一部分，當需要的時候就改變狀態（state）。我會處理其他的事情，重新渲染需要被渲染的介面。

應該說，只有 React 框架還不足以解決麵條式程式碼。因為狀態也可能出現在各個奇怪的地方，或者狀態起的名字很糟糕，或者用莫名其妙的方式呼叫。

以我有限的經驗來看，Redux 庫才能真正解決麵條式程式碼的問題。Redux 說：我會處理所有重要的狀態，都是全域性的，不是元件依賴的。我才是唯一的資料來源。如果你需要改變狀態，就要採用特定的儀式（我聽說它是這麼叫的，而且我喜歡這麼叫）。通過 reducers 和被分發的（dispatched） actions，所有的改變都會遵循這種儀式。

如果你準備在專案中加入 Redux（或者 Redux 的變種），那麼你就可以和硬編碼說再見了。通過加入 Redux 框架，元件會變的高內聚，也很容易理清整個需求的邏輯走向了。

要管理大量的DOM

手動處理 DOM 可能是引起麵條式程式碼的最大原因。

1. 在這裡插入一段 HTML ！

2. 在這裡把某些東西分離出去！

3. 監聽特定區域的特定事件（event）！

4. 在這裡繫結一個新事件！

5. 又來了新內容。再次插入到 HTML 裡，確保它繫結了正確的事件！

此類事情可以發生在一個 app 的任何地方、任何時間，這就造成了麵條式程式碼。手動管理是不靠譜的，因為這麼做的話又變成 DOM 資料來源了。很難準確的知道某個給定的元素髮生了什麼，所以每個人只好直接查詢 DOM ，做他們必須做的事情，順便向上帝祈禱他們這麼做沒干擾到別人。

React 框架說：你不需要直接操作 DOM 。我用虛擬 DOM 來處理真實的 DOM。如果你想要操作 DOM，可以直接在虛擬 DOM 上操作。通過這種方式，所有的邏輯就有跡可循了。

管理複雜的 DOM 是另一件適合 React 框架的事情。想象有一個聊天軟體，當資料庫接收到其他聊天者傳遞來的新聊天資訊時，在聊天視窗裡應該顯示這些新的資訊。否則你只能自己給自己聊天了！或者當聊天頁面第一次被載入的時候，可以從本地資料庫裡找出幾條舊資訊顯示出來，這樣你立刻有東西可以看了。比如說這個推特例子。

只是因為，React 框架是目前最火的框架。

學習新東西是很酷的，所以學習吧！

為了滿足使用者的需求而構建專案則需要更謹慎一點。

舉個例子，一個部落格也許沒什麼複雜的邏輯，一點也不符合應該使用 React 框架的情況。所以如果不是很適合的話，那麼也許就是很不適合 React 框架。因為這麼做引入了複雜的技術，依賴了很多根本沒用到的東西。

在完全適合和完全不適合之間，如果這個部落格是一個 SPA （“單頁面應用”，不需要瀏覽器重新整理），通過 headless CMS 獲取資料構建該部落格，並且具有出色的服務端渲染…好吧，也許又是 React 框架的領域。

如果是 web app CMS 建立的這種部落格？也許用 React 是一個好選擇，因為它也有一大堆的狀態。

我就是喜歡 JavaScript ，就是想用它來編寫任何東西。

我經常安利周圍的人：學習 JavaScript。因為 JavaScript 的知識太豐富了。它能做很多很多的事情，也有很多的工作機會，所以好好學習 JavaScript 永遠不會過時。

只有在最近的網路技術歷史裡，Javascript 才可以做所有的事情。你通過 Node.js 構建服務端，也有很多專案可以通過 JavaScript 處理 CSS。現在通過 React 框架，你還可以在 JavaScript 裡寫 HTML。

萬物歸於 JavaScript！JavaScript 萬歲！

React 確實碉堡了，但是你可以用 React 並不意味著你必須用 React 。並不是所有的專案都必須使用它 ，而且事實上，有相當一部分有可能壓根不需要它。

️ 這就是我所知道的。

（是或者否都可以找到合適的圖示來表達，但是想表達也許的意思就比較複雜）（譯者注： 指作者此處用太極的圖示表示也許的意思。）

你在學習，太好了。每個人都在學習，所以堅持學習吧。你知道的越多，你越知道該用什麼技術更好。

但是很多時候你只能以現有的技術來構建專案，所以我也不會反覆強調這一點。

️ 這就是工作。

在給定的任何專案中，不是每個人都可以由有權利決定應該底用什麼技術。希望隨著時間的增長，你可以更大層度上的影響決策。Eden 說她花了兩年的時間研究 Ember，因為這就是她的工作。沒有任何冒犯的意思，但是拿人錢財就得替人消災。Ember 也許比較適合這些專案。