為什麼我要從 Angular 遷移到 React 和 Redux ?

類別: IT

我對 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

  • 建立一個 由 DispatchersActionsReducers 組成的 Redux store

  • 把你的元件連線到 Redux Container

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

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

現在,讓我們來看看 Angular 是如何做的:

帶有 Service 的元件作為中心連線一個元件與另一個元件進行通訊。

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

為了讓元件彼此通訊,你需要執行以下操作:

  1. 建立包含事件發射器的服務,以使每個元件的通訊成為可能。

  2. 建立可以響應使用者在全域性元件中操作的事件發射器。

  3. 為將使用全域性事件的每個元件注入服務。

  4. 為將使用它們的每個元件建立事件發射器,並在訂閱服務中建立事件。

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

你仍然完成需要冗長的設定,以便開始在元件彼此之間通訊。

為什麼我要從 Angular 遷移到 React 和 Redux ?原文請看這裡