2017-07-14 65 views
0

目前重構角應用程序中使用NGRX店,有兩個選擇。這是我們的應用程序的基本結構。我相信大多數的角應用都是建立在相同的方式:NGRX和國家管理的子組件

AppComponent 
|-- ContainerComponent 
    |-- ChildComponent1 
    | |-- GrandChildComponent 
    |  |-- GrandGrandChildComponent 
    |-- ChildComponent2 

的ContainerComponent注入Store<AppState>。我試圖解決的問題是,GrandGrandChildComponent(比如DropDownMenu組件)必須根據應用程序的狀態來改變它的行爲(即在商店中發生的某些情況下禁用某些菜單項),並在點擊時發出一個事件在菜單項上如此ContainerComponent(或任何其他組件,沒有必要的祖先)可以對它作出反應。

有一對夫婦的解決它的方法:使用@Input/@Output

  • 進樣Store到任何組件

    1. 通信的組件之間需要知道狀態

    選項1是什麼我在文檔中閱讀的最常見/推薦的模式。所以只有ContainerComponent是胖的,所有的孩子都很瘦/笨,並且依賴於通過@Input進入的狀態。

    但從我看到的這種方法增加了很多樣板,你必須添加不必要的屬性只是爲了將狀態傳遞給Grand 子組件。而且它打破了關注點分離的原則,因爲任何中間組件都必須知道下面的組件需要什麼。如果知道僅在Grand組件上可用的詳細信息,那麼製作通用組件並不容易。

    在另一方面,方法2似乎解決的分離關注的問題,它似乎也更清潔的實現。但由於我在使用redux模式方面比較新,所以我不確定這是否可行,也許我不知道在重構過程中可能面臨的任何缺陷。

    IMO,這兩種方法提供每個組件的測試的一個簡單的方法是一個巨大的對我。

    我在這接近採取懷疑。我應該知道哪些缺陷?

    感謝

  • 回答

    2

    這裏是終極版的丹·阿布拉莫夫的創造者(NGRX的靈感來自終極版讓很多的方法同樣適用於NGRX)必須在話題說:

    何時引入集裝箱?我建議你先開始構建你的應用程序 ,只需展示組件。最終你會意識到 你正在向中間組件傳遞太多道具。 當您發現某些組件不使用它們收到的道具時,只是將它們向前移動,並且您必須在所有孩子需要更多數據時重新連線所有那些中間組件,這是介紹某些容器組件的好時機。通過這種方式,您可以獲得 數據和行爲支持葉子組件,而無需 爲樹中間的不相關組件增加負擔。這是 正在進行的重構過程,因此不要嘗試第一次將它正確地設置爲 。在您嘗試使用這種模式時,您將開發一個直觀的感覺,以便何時抽取一些容器,就像您知道何時抽取函數一樣。

    來源: https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0#7dc5

    1

    這在很大程度上取決於你的使用情況爲每個組件是否多少@Output和@input他們。

    我一直在使用你的1st方法一段時間,如果你的Child/lower-order組件做非常簡單的交互(取數據自頂向下,然後發回Event給Parent)或者一個愚蠢的組件(只需要輸入)。確定我的容器非常大

    但是,如果您的某個子組件擁有多個I/O並且擁有許多其他子組件也具有相同的子組件,則您可能需要將它們視爲一個Big-Child (來自Child的@Output()將保留在Big-Child組件中,而不是傳遞給GrandParent組件)

    從下往上有太多的@Output()可能會給你頭痛以及:)。第二種方法將使您的組件更易於閱讀。

    AppComponent |-- ContainerComponent |-- ChildComponent1 | |-- GrandChildComponent | |-- GrandGrandChildComponent |-- ChildComponentWithManyIO => Make them to be self-managed |--GrandChild with only Input |--GrandChild with many Inputs/Outputs (Self-managed)

    我管理國家的思想從這裏上來:https://www.youtube.com/watch?v=eBLTz8QRg4Q