為什么我要從 Angular 遷移到 React 和 Redux ？

我對 Angular 又愛又恨已經有一段時間了。這很有趣，因為我正在學習，而且在做一個簡單的應用程序時，我被卡住了好幾周。

我注意到，即使在制作最簡單的特性的過程中，我甚至不確定它是否值得使用 Angular 。我徹底掌握了基本的基本原理，這足以使小的特性發揮作用。

但是，它沒有成功。更糟糕的是，我甚至根本不使用 Javascript 。它更像是一種完全不同的語言。

我喜歡 Typescript  ，但不知怎的，我在使用它時變得煩躁不安，因為我花了很多時間來掌握 Javascript 的細節。而且感覺我還在做一些后端工作(依賴注入、服務等)。奇怪的是，所有的事情都讓人感到熟悉和沮喪。

然后有一天，我最終放棄使用 Angular 并尋找諸如 React  和  Vue  等其他選擇。我在 2015 年 React 發布時有嘗試過 React 。我記得它當時處于測試階段，有很多人都在談論它。 我不明白它的全部流程，比如 “ state ” 。

但在 2017 年第四季度左右，我嘗試重溫并觀看與 React 和 Redux 相關的課程。 我很好奇大家為什么對這個庫感到大驚小怪，它在 2017 年左右瘋狂流行，其所謂的數據不變性也在大肆宣傳。

我喜歡 AngularJS（ Angular 的第一個版本），以至于我喜歡它的“怪癖”并對它進行了很多研究。 但是，當我轉移到 Angular 2+ 并投入了時間去研究時發現，我覺得有些東西不對，并且出于某種原因，它可能無法提供 React 中最簡單的功能。 

快速使用：最后我很高興我做到了。 一旦你了解  React  的基本原理，實際上很容易實現這些基本功能。

我幾個月來一直在我的新項目中使用 React ，并且我可以真正地說我沒有后悔嘗試使用 React 生態系統。 從那以后，我再也不用依靠 Angular 了。

所以，如果你可能會問：是什么讓我從 Angula 轉到 React ？ 僅僅只是靈活性嗎？

小爭論：不要拿蘋果和橘子比較

我的意思是在這兩個生態系統中我都沒有受到任何損失，可能我們只是說，在 React 中整合新功能比 Angular 更容易，因為 React 是一個 庫 ，Angular 是一個 框架 。 大多數人都忽略了兩者之間顯著存在的巨大差異。

當你使用一個庫時，它只是你應用程序的一部分。所以顯然，學習曲線也很小，你甚至可以混合使用其他一些庫。

框架對你開發影響是很大的。而且你應該遵守他們的標準使用方式（例如做 http 請求，組件綁定，事件綁定等）。簡而言之，在使用 Angular 的情況下，你需要以“ angular ”的方式來做事情。因為你使用的是框架，所以你必須遵循它。 

這與只負責視圖部分的 React 情況不同。除此之外，你可以自行發現可能想要用于執行 http 請求以及訂閱密鑰綁定的內容。你可能想要使用 Redux 或  Flux 來進行數據存儲和狀態管理。你有很大的自由空間。

那么，下面是我現在使用 React 的原因：

它是一個庫。因此，你可以附加任何你想要的 JavaScript 庫作為附加組件

這很明顯，因為 React 只是另一個 JavaScript 庫，而不是框架。如前所述，在 React 中，你可以輕松地附加任何想要的庫。只要你知道你在做什么，它并不關心 JavaScript 中的堆棧環境。 React 的理念圍繞“樂高積木”的概念展開。這是你可以在庫中獲得的一個重大優勢，也是你可以擁有的最強大的好處之一。我們都知道技術來來去去基本都是那幾種。那么為什么你仍然需要把大部分時間都花在學習一個框架中呢？

這就是為什么我切換到 React 的原因：只使用我需要的東西。我可能不需要全面的框架，因為我不會以其他的方式使用框架的大部分功能。關鍵是，不管你的應用是過度設計還是架構良好，你仍然無法躲避在過程中引入錯誤的現實。既然如此，為什么還要過度設計？

當我嘗試創建一個涉及附加全局事件處理程序的功能時，在 Angular 中，為了實現這個功能而需要做大量工作！

我搜索了幾次 StackOverflow ，答案都是一樣的。為了完成這項工作，需要經歷一系列的挑戰，實際上就是需要 大量開發工作 。 但我通過使用 Event Emitters 只花了一天時間就解決了這個問題。也就是說，對于一些簡單的事情，它仍然需要大量的工作。

我并不是說 Angular 執行得不夠好。 但是，可能我仍然需要投入大量時間才能完成簡單的工作。

React 通過使用另一個名為 mousetrap  的 js 庫來實現這一點，以實際綁定整個應用中的全局鍵值。 現在我可以使用我在 Vanilla JavaScript 中學到的東西了。

P.S：React 具有極大的靈活性的同時也具備良好的職責分工。

狀態管理更加靈活

如果沒有像 Flux 和 Redux 這樣的庫補充到 React 生態系統中，我可以說， React 可能與 Angular 依賴注入和服務模式是同等的。我不太喜歡使用這些模式，特別是在做一些前端的事情時。也許我只是不習慣使用它，因為在后端使用它更有意義，但在前端更少。

在我開始使用 React 和 Redux 一段時間后，我注意到，管理狀態和在組件的不同部分分配那個狀態是多么容易和輕松。這很神奇，因為它更強調每個 React 和 Redux 結合在一起的“狀態”。

那么為什么它這么重要？因為它使你的溝通在你的組件的所有部分看起來毫不費力。你只需要發送一個動作，創建一個減速機，連接并知道它是什么 “state” ，瞧! 這個狀態將反映在所有使用它的組件中，只要你修改了該狀態。只有當你使用 Flux 和 Redux 時，這才是正確的。

一個理想的用例是當兩個或多個組件依賴相同的數據或狀態時，只需通過簡單地將組件連接到 Redux 來輕松地檢索它們。例如，我的儀表盤上的組件都需要同樣的數據，并很好的在模態框中顯示，以讓我更容易把它們連接起來。

為實現這個目標，你需要做以下的事情：

• 在你的 React App 中加入 Redux

• 創建一個 由 Dispatchers ,  Actions ,  Reducers  組成的 Redux store

• 把你的組件連接到 Redux Container

• 在你的組件內部使用 Application State

當然，在這樣做時，你也必須小心，因為隨著應用的增長，它可能會變得更加混亂。在所有的靈活性中總是有一個權衡，無論是編程語言還是庫。 Abramov 在他的博客中進一步表示： 你可能不需要 Redux 。

現在，讓我們來看看 Angular 是如何做的：

帶有 Service 的組件作為中心連接一個組件與另一個組件進行通信。

全局狀態方法也可以用 Angular 2+ 的方式進行。你可能會說，它與 React 工作方式完全不同，因為它使用 服務模式 作為 Angular 核心模式，主要是為了迎合 API ，使單元測試更容易。

為了讓組件彼此通信，你需要執行以下操作:

1. 創建包含事件發射器的服務，以使每個組件的通信成為可能。

2. 創建可以響應用戶在全局組件中操作的事件發射器。

3. 為將使用全局事件的每個組件注入服務。

4. 為將使用它們的每個組件創建事件發射器，并在訂閱服務中創建事件。

5. 確保事件發射器將被取消訂閱，以使事件只觸發一次。

你仍然完成需要冗長的設置，以便開始在組件彼此之間通信。

 

來自：https://www.oschina.net/translate/why-im-switching-from-angular-to-react-and-redux-in-2018