我在Redux的数据建模我的商店

Question

想一想：

我有一个应用程序，它最终会变得非常大。它是一个仪表盘，可以让你访问各种实用程序，其中一个是待办事项应用程序。

如果我只是要建立只是一个待办事项应用程序，然后我的状态对象看起来像这样：

{ todos:[], completed:false, todoInput:''};

todoInput将被捆绑到一个窗体域，并在点击添加，它会更改todos数组并切换completed字段。所以我的combineReducers()函数看起来像这样。

combineReducers({todos,completed,todoInput});

，因为所有的状态是相关的待办事项应用程序，因为仅仅是一个待办事项应用这将使感。

现在，因为我建立一个更为复杂的应用程序，它也有一个待办事项应用程序，这是怎么了我的状态将有可能是这样的：

{ 
    otherState:'',evenMoreState:[]',evenMore:{}, 

    todo:{ todos:[], completed:false, todoInput:''} 
} 

正如你可以看到我已经分离的待办事项到一个单独的对象现在，它是封装和更有组织的。所以我有两个问题。

1）这是个好主意吗？这似乎是合乎逻辑的举动，因为我的应用程序的规模会增大，我不希望所有的状态都作为主状态对象的属性浮动。我是否正确地处理了这个问题？

2）我的联合减速器（据我所知）不能采取嵌套的对象。所以它现在看起来像这样。

combineReducers({ otherState,evenMoreState,evenMore,todo})

所以现在我减速的组合物将具有处理待办事项状态机内部工作要做。有没有更好/不同的方式来做到这一点？

谢谢

Answer 1

是的，你绝对是在正确的轨道上。另外值得一提的是，你可以使用combineReducers多次，如：

const rootReducer = combineReducers({ 
    otherState : otherStateReducer, 
    todos : combineReducers({ 
     todos : todosReducer, 
     completed : todosCompletedReducer, 
     todoInput : todoInputReducer 
    }) 

整体todos部分可以分别定义，和进口，如果需要在顶层combineReducers呼叫引用。 }）;

您可能想要阅读Redux docs section on "Structuring Reducers"以获取有关组织减速器逻辑的方法的更多信息，以及Redux FAQ on organizing nested state。另外，我的React/Redux links list的Redux Techniques和Redux Architecture部分有关于构建真实世界Redux应用程序的各种文章的链接。