解析器與 Redux

Question

我已經在 Angular 的中小型項目中工作了很長時間，只要有一些數據需要從服務器加載，團隊就會直接將其存儲到 Redux 存儲中。 這允許在用戶在“頁面”之間導航以及他們決定刷新頁面時保留數據。

但是，最近我一直在做一個“正確的” Angular 教程，我們設法通過結合服務（在app.module.ts中提供）來保留數據和解析器來實現相同的結果。 解析器確保在加載我的主頁時，將所需的數據加載到服務中。 此外，如果數據不是太大，我什至可以將其存儲到localStorage中，因此，如果數據不存在，則消除解析器中的HTTP請求。

除了不太可能的用例 1. 需要加載大量數據和 2. 用戶出於某種原因經常刷新網頁，我真的不明白為什么我們應該實現一個完整的 redux 存儲。

是否有更多理由使用我不理解的 Redux，或者使用這種方法有更多缺點？

Answer 1

這是redux的創造者的一篇非常有名的文章。 它被稱為你可能不需要redux。

Angular 是一個已知解決數據間依賴問題的框架。 如果事件和數據綁定的組件間通信對您有效並且通過服務進行緩存是可以的，不會導致以下問題，那么您應該堅持使用它們。

為什么？

1. Redux 對於大多數學習曲線陡峭的開發人員來說是違反直覺的
2. 需要大量樣板代碼，如果你不需要它的權衡，那么你不應該打擾它

Redux 和焊劑通常被誤解並以錯誤的方式廣泛使用。 有跡象表明您需要使用 redux ，您可以在angular univercity中看到。 它幾乎說以下內容

React 組件按層次結構排列。 大多數情況下，您的數據 model 也遵循層次結構。 在這些情況下，Flux 不會給您帶來太多收益。 但是，有時您的數據 model 不是分層的。 當你的 React 組件開始接收感覺無關緊要的 props，或者你有少量組件開始變得非常復雜時，那么你可能想要研究 Flux。

你有一條數據需要在你的應用程序的多個地方使用，通過 props 傳遞它會使你的組件打破單一職責原則（即讓它們的界面變得不那么有意義）

有多個獨立的參與者（通常是服務器和最終用戶）可能會改變該數據

在任何其他情況下（並且當上述示例受到限制時），我會選擇不使用 redux 的 go 並使用 angular 開箱即用的解析器、防護和服務。