设计全局状态和组织 Reducer

个人认为如何设计全局状态和组织 reducer 其实是很重要的一件事,例如什么状态应该放在 reducer 里什么不应该,这会影响到应用的性能以及可维护性。官方已经对此有很好的说明,但大家似乎都忽略了。 这一节是对官方文档 Structuring Reducers 的重点摘要,以及补充了个人经验。在这里我们不谈代码上编写 reducer 或者是 combineReducers 等技术细节上的问题

正如本书开头所说,在设计 reducer 之前,首先应该考虑的是数据真的需要放在 redux 中吗?请总是尝试使用 state 解决问题

区分领域模型

全局状态和 reducer 本质上是 model 概念在 redux 下的实现。前者是对领域模型(通俗的可以理解为不同业务的状态数据)的划分,后者对业务逻辑的封装。总体来说模型可以划分为以下三类:

领域数据(Domain Data):应用需要展示的数据,比如所有的 todo list

应用状态(App State):应用行为相关的数据,比如选中了 5 个 todo

UI 数据(UI State):比如某个对话框是否浮现,某个面板是否展开

应用应该围绕「领域数据」和「应用状态」来设计状态和 reducer,而不是 UI 数据。比如state.leftPane.todoList.todos 就是一个糟糕的设计,因为 todolist 和 leftPane 没有业务上的关系,也更不是从属关系。

绝大部分应用不会主动的记录 UI 状态,如果需要也可以依靠组件的内部 state 完成。如果确实需要,可以在 redux 中以独立于 domain data 与app state 的形式进行记录:

{
    domainData1 : {},
    domainData2 : {},
    appState1 : {},
    appState2 : {},
    ui : {
        uiState1 : {},
        uiState2 : {},
    }
}

数据扁平化

results matching ""

    No results matching ""