Redux:组织容器、组件、动作和化简器

问题：

在

大型中组织容器、组件、动作和减速器的最可维护和推荐的最佳实践是什么 React/Redux application？

我的意见：

目前的趋势似乎是围绕相关的容器组件组织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

这很好用！尽管此设计似乎存在一些问题。

问题：

当我们需要访问 actions ，从另一个容器selectors或sagas，这似乎是一种反模式。假设我们有一个全局/App容器，其中包含一个化简器/状态，用于存储我们在整个应用中使用的信息，例如类别和可枚举项。从上面的示例开始，使用状态树：

{
    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传奇、操作和选择器。我们可能有容器/PasswordRecover、/PasswordReset、/Login、/Signup....实际上，在我们的应用程序中，我们的/Auth contianer 根本没有实际组件！

/src
    /contianers
        /Auth
            actions.js
            constants.js
            reducer.js
            selectors.js
            sagas.js

简单地包含上面提到的各种通常不相关的身份验证容器的所有 Redux 抵押品。