[譯] 項目何時須要 React 框架呢？

• 原文地址：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 也許比較適合這些項目。

• 相關譯文：哪些項目須要 React？都須要！ 譯者 sun

---

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