Redux/ngrx/store體系結構：爲什麼不從啞組件分派操作？

我正在構建一個Angular 2 ngrx/store應用程序，並試圖瞭解最佳實踐。Redux/ngrx/store體系結構：爲什麼不從啞組件分派操作？

我喜歡有一個不可改變的狀態，只能根據調度的動作進行更改，以便應用程序狀態非常清晰且可調試。
我喜歡從「智能」容器向下的單向數據流，因爲這允許我們使用異步管道來減少對狀態的檢查。

但我不明白爲什麼我們希望在將操作分派給商店之前，將愚蠢組件的事件「泡」到智能組件。是否有可重用組件的唯一原因？在我看來，大多數組件不會被重複使用，因爲當我想要使所有內容都相同時（包括CSS），並不是很多情況。我錯過了其他好處嗎？從可維護性/可讀性的角度來看，能夠看到正在發生交互的組件上發生的動作是否更好？

來源

2016-06-16 David

在使用ng> 2一段時間後，我開始意識到ngrx/effect和smart-container是你的兩個設計選擇。如果您使用ngrx /效果，那麼您不需要使用Smart-Dumb組件。 –

[React/Redux - 保存選擇值onChange]的可能重複（https://stackoverflow.com/questions/44549916/react-redux-save-select-value-onchange） –

我完全同意你和我有同樣的疑問。

我期望組件使用調度器（對於ngrx/store是商店本身）發出一個操作，而不是將此邏輯移動到容器（實際應用程序）。

通過這種方式，組件與容器分離並且容器不需要知道操作：它只會監聽狀態更改並在必要時傳遞最終數據。

另一方面，Introduction to ngrx/store正在推出更智能的容器的設計，該容器對底層組件有很多瞭解。

坦率地說，我還不能看到明顯的勝利者：我只是覺得，從組件調度操作更簡單，更清潔和更接近Elm Architecture這是終極版的靈感之一。

來源

2016-06-30 07:57:30 pietro909

請參閱Dan Abramov（Redux創作者之一）https：// medium的文章。com/@ dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0他說他現在已經修改了他的方法，很高興在「啞」組件中嵌套「智能」組件（儘管他現在使用不同的名字），引用作爲一個實現細節的靈巧性 –

謝謝，實際上我讀過它。但與此同時，我完全轉向了Elm和一些React Native，並且我獲得了重生：D – pietro909

我還沒有在ngrx/example-app的頂部組件找到任何有關「冒泡」事件的參考。在Rob的談話中，我還沒有得到（我可能錯過了一些東西）。

我只是使用所有的ngrx作爲例子，現在看起來很好。 ngrx/store存儲數據，ngrx/effects到連鎖動作（我可以簡化），以及「動作」圖像中的「中間件」，描述了您可以使用其中一個存儲部件執行的所有操作。

然後，當它看起來最方便我使用的行動（我只是確保文件中使用的所有操作都與當前類相關）。

來源

2016-06-16 18:51:50

例如，在book-detail.ts中，它發出事件添加和刪除。然後在其父組件（book-view.ts）中，它接受該事件並分派一個操作。爲什麼不直接派發書本細節？這種情況並不嚴重，因爲它只是一個級別。但是，如果你在一個更復雜的應用程序中有多個級別的組件，我可以看到輸出事件的「冒泡」是非常煩人的。 – David

看來，所有愚蠢的組件似乎是像MD輸入或按鈕或簡單的元素，你可以得到。您不希望將商店邏輯限制在該組件上，因爲如果您決定改變有關您的操作，縮減器或效果或其他商店邏輯的內容，則需要更新您擁有的每個啞組件。如果你把所有的邏輯都保存在「根」組件中（比如頁面 - 元素直接顯示在路由器上），你只需要更新其中的幾個（輕鬆訪問）。所以它基本上保持健康的應用程序。 –

我不同意你@PiotrGrużewski：我認爲屬於消息傳遞（然後是動作）的邏輯應儘可能隱藏，以便容器可以專注於實際應用程序的邏輯而不是基礎設施。將事件暴露給容器，然後將它們轉化爲行動，在我看來，是多餘的。另一方面，我認爲讓組件直接使用商店還不是一個完美的解決方案：我們可能需要一個合適的調度員？ – pietro909

其中一個主要原因是重複使用。

就MVC而言，將您的智能組件視爲您的控制器，將您的智能組件視爲您的視圖。

想象一下，爲您的某個實體（模型）呈現編輯表單的愚蠢組件。啞元組件處理顯示錶單和驗證消息，但是您可以在添加實體屏幕，編輯實體屏幕上重新使用該組件，也可以在應用程序中的其他位置彈出對話框。這些用例中的每一個都需要具有相同驗證的相同表單，但是您可能會在「提交」時執行截然不同的操作。調用愚蠢組件的智能組件在每種情況下可能都是不同的智能組件。通過提升事件並將值傳遞給智能組件，您可以執行完全不同的操作，同時只編寫一次「視圖」。

來源

2016-07-02 00:59:58

好的答案，這是在不同用例中重複使用相同表單的一個好例子。 –

首先，我不是主題免責聲明的專家。

我覺得智能部件控制啞分量其實就是它被稱爲調解模式。使用此模式可確保更少的組件必須處理store，從而增強蝨耦合。
易於維護：如果您不得不重構和批量重命名操作，則操作在更少位置出現時更容易。
擁有一個處理actions的中心位置允許該架構的快速概述。訪問邏輯的熱插拔也可以更容易完成。
而且已經提到：重用。您可以在具有或不具有ngrx體系結構的項目之間共享和重用愚蠢組件。
只需連接不同的inputs和outputs即可在同一個項目中重複使用。例如：A dropdownComponent可能有很多需要不同輸入和輸出的用例。

來源

2016-10-22 21:55:14

Redux/ngrx/store體系結構：爲什麼不從啞組件分派操作？

回答

相關問題