什么是组织在一个大 React/Redux应用程序容器,组件,动作和减速的最易维护和建议的最佳实践?
我的看法:
目前的趋势似乎组织Redux的抵押品(动作,减速机,传奇......)围绕有关的容器组件。例如
/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
This works great!虽然这种设计似乎有几个问题。
的问题:
当我们需要从它似乎是一个反模式的另一个容器访问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,
}
},
}
如果我们要使用selector
从/App
容器我们/BookList
容器,我们需要可以重新创建它在/BookList/selectors.js
内(当然错了吗?)或导入它从/App/selectors
(它会永远是相同的选择器..?否)。这两种说法对我来说都不是最理想的。
这个用例的主要例子是身份验证(ah ... auth,我们喜欢讨厌你),因为它是一个非常有效的常见的“副作用”模型。我们经常需要访问各种应用程序中的传奇故事,动作和选择器。我们可能有容器/PasswordRecover
,/PasswordReset
,/Login
, /Signup
....实际上在我们的应用程序中我们的/Auth
contianer根本没有实际的组件!
/src
/contianers
/Auth
actions.js
constants.js
reducer.js
selectors.js
sagas.js
简单地包含上述各种通常不相关的身份验证容器的所有Redux资料。
我很好奇,你现在的结构如何使用你的选择器?假设一个组件使用'BookList'选择器函数,你能告诉我你的'mapStateToProps'函数吗?你是否在传递'状态'?或'state.booklist' – xiaofan2406