问题:
在一个大型React/Redux应用中,组织容器、组件、操作和减速器的最可维护和推荐的最佳实践是什么?
我的观点:
目前的趋势似乎是围绕相关的容器组件来组织redux的附属内容(操作、减速器、saga等)。
/src
/components
/...
/contianers
/BookList
actions.js
constants.js
reducer.js
selectors.js
sagas.js
index.js
/BookSingle
actions.js
constants.js
reducer.js
selectors.js
sagas.js
index.js
app.js
routes.js
这个很好用!不过这个设计似乎存在一些问题。
问题:
当我们需要从另一个容器访问 actions、selectors 或 sagas 时,似乎会出现反模式。假设我们有一个全局的 /App 容器,其中包含一个 reducer/state,存储我们在整个应用程序中使用的信息,如类别和枚举。继续上面的示例,有一个状态树:
{
app: {
taxonomies: {
genres: [genre, genre, genre],
year: [year, year, year],
subject: [subject,subject,subject],
}
}
books: {
entities: {
books: [book, book, book, book],
chapters: [chapter, chapter, chapter],
authors: [author,author,author],
}
},
book: {
entities: {
book: book,
chapters: [chapter, chapter, chapter],
author: author,
}
},
}
如果我们想要在
/BookList
容器中使用来自/App
容器的selector
,我们需要在/BookList/selectors.js
中重新创建它(这肯定是错误的?)或从/App/selectors
导入它(它总是完全相同的选择器吗?不是)。这两种方法似乎对我来说都不太理想。这种用例的主要示例是身份验证(啊...身份验证,我们确实很讨厌你),因为它是一个非常常见的“副作用”模型。我们经常需要在整个应用程序中访问
/Auth
sagas、actions 和 selectors。我们可能有容器/PasswordRecover
、/PasswordReset
、/Login
、/Signup
.... 实际上,在我们的应用程序中,我们的/Auth
容器根本没有实际组件!/src
/contianers
/Auth
actions.js
constants.js
reducer.js
selectors.js
sagas.js
这只是包含了所有Redux文物的容器,用于各种不同的、常常不相关的身份验证容器。
BookList
的选择器函数,你能给我展示一下你的mapStateToProps
函数吗?你是通过传递整个state
还是只传递state.booklist
? - xiaofan2406