為React / Redux應用程序構造狀態

Question

我正在努力構建一個React / Redux應用程序-我列出了我為解決方案嘗試的選項的問題，但沒有“感覺正確”的東西，因此希望這里的人能為我提供幫助。

這是我的組件結構的大致概念：

<Dashboard>
    <Widget1 dataFetcher=()=>{}>
        <Header>
            <Title> ... </Title>
            <Menu>
                <MenuItem {..cosmeticProps} text="OpenSettings" onClick=handleSettingsOpen>
                <MenuItem {..cosmeticProps} text="Delete" onClick=handleWidgetDelete>
            </Menu>
        </Header>
        <Body>
            <Settings isOpen isValid fields onValidate onAutoComplete.. </Settings>
            { ifError ? ErrorLayout}
            { ifFetching ? FetchingLayout }
            { ifValid ? DataLayout }
        </Body>
    </Widget1>
    ...
</Dashboard>

這是狀態結構（顯示事件處理程序是為了保持完整性，而不是因為它們顯式屬於狀態）

Dash: {
    widgets: {
        widget1: {
            menu: {
                isOpen: true,

                handleSettingsOpen: ()=>{}
                handleWidgetDelete: ()=>{}
            }
            settings: {
                isOpen: true,
                isValid: true,
                fields: [...],

                onValidate: ()=>{},
                onAutoComplete:()=>{},
                onSave:()=>{}
            }
            data: {
                isFetching: false,
                isError: false,
                items: [],

                fetch: ()=>{}
                parse: ()=>{}
            }
        }
        ...
    }
}

選項1：

連接儀表板，並根據需要將其傳遞給子級。 即

連接 - dashboard.js

stateToProps ()=> { widgets: state.widgets }
dispatchToProps ()=> { handleSettingsOpen, handleWidgetDelete handleSettingsSave ... } //Dashboard would bind these with moduleid while rendering

優點：其他一切都可以是“啞巴”，單一的真理來源
缺點：對狀態了解太多，只是傳下來的道具/調度清單使閱讀變得難看

選項2：

構建一個“已連接”的小部件，並在儀表板中使用它。

連接-widget.js

stateToProps ()=> { state.widgets[props.widgetid] }
dispatchToProps ()=> { handleSettingsOpen, handleWidgetDelete handleSettingsSave ... }

優點：儀表板現在可以是一個啞容器，無論如何都可以
缺點：Widget對狀態結構了解得太多？

選項3：構建各個組件的連接版本並稍后組裝

連接-menu.js

stateToProps ()=> { state.widgets[props.widgetid].menu }
dispatchToProps ()=> { handleSettingsOpen, handleWidgetDelete }

連接-settings.js

stateToProps ()=> { state.widgets[props.widgetid].settings }
dispatchToProps ()=> { handleSave, handleValidate }

優點：每個組件都能准確獲取其關心的狀態
缺點：監聽狀態的組件過多？ 還有誰“組裝”它的問題。

選項3.1：將狀態重構為：

Dashboard: {
    widgets: { ..}
    menu: {widgetid: {isopen ..}}
    settings: {widgetid: {widgetid ..}}
}

（國家采用這種方法比較討人喜歡，但不確定是否重要）

總體而言，這可能是幼稚的/顯而易見的，但對我而言，折衷方案似乎是讓父母對州知之甚少，或者對孩子的子女過分了解太多。 您將如何處理？

Answer 1

選項3：“菜單”和“設置”知道“ widgetId”是否有意義？ 如果它們分別分別接收屬性菜單或設置，它們似乎將更可重用。

選項1：是否要為支持的每個窗口小部件組件更新Dashboard stateToProps和dispatchToProps？

由於這些原因，我喜歡選項2，即連接的Widget1。

至於狀態嵌套深度， Redux異步操作具有“關於嵌套實體的說明”，建議避免使用深度嵌套的實體以避免重復數據。

在您的示例中，如果任何窗口小部件具有重復的菜單或設置狀態對象，則標准化狀態將允許窗口小部件共享相同的狀態。

Dashboard: {
    widgets: {
        widget1: {menuId:1, settingsId: 1, ...},
        widget2: {menuId:1, settingsId: 1, ...},
    },
    menus: {1: {...}},
    settings: {1: {...}}
}

實際上，通過這種結構，“菜單和設置”僅需要知道menuId或settingsId，而無需知道widgetId。 我仍然更喜歡連接小部件。

為React / Redux應用程序構造狀態

問題描述

1 個解決方案

解決方案1
0 2016-04-06 16:26:35

為React / Redux應用程序構造狀態

問題描述

1 個解決方案

解決方案1 0 2016-04-06 16:26:35

解決方案1
0 2016-04-06 16:26:35