Javascript 如何构建 Redux 组件/容器

How to structure Redux components/containers

提问by Franco Risso

I'm using redux and I'm not sure about how to organize my components, I think the best is to keep them in folders with the name of the main component as the name of the folder and all inner components inside:

我正在使用 redux 并且我不确定如何组织我的组件，我认为最好将它们保存在文件夹中，其中主要组件的名称作为文件夹的名称以及其中的所有内部组件：

components
  Common/   things like links, header titles, etc
  Form/     buttons, inputs, etc
  Player/   all small components forming the player
    index.js  this one is the top layout component
    playBtn.js
    artistName.js
    songName.js
  Episode/  another component

Then, in the containers folder, I've one container per page, that are the only ones I'm actually connecting to Redux:

然后，在容器文件夹中，我每页有一个容器，这是我实际连接到 Redux 的唯一容器：

containers/
  HomePageApp.js
  EpisodePageApp.js
  ...

and then the actions are one per each top component, instead of one per page, so in the page container that I connect to Redux I pass all the actions of the components used in that page. For example:

然后动作是每个顶级组件一个，而不是每个页面一个，所以在我连接到 Redux 的页面容器中，我传递了该页面中使用的组件的所有动作。例如：

actions/
  Player.js
  Episode.js
  ...

Am I doing this right? I haven't found much information about it googling, and the ones I've found I think they are limited to small projects.

我这样做对吗？我在谷歌上没有找到太多关于它的信息，我发现的那些我认为它们仅限于小项目。

Thanks!

谢谢！

回答by Dan Abramov

In the official examples we have several top-level directories:

在官方示例中，我们有几个顶级目录：

• componentsfor “dumb”React components unaware of Redux;
• containersfor “smart” React components connected to Redux;
• actionsfor all action creators, where file name corresponds to part of the app;
• reducersfor all reducers, where file name corresponds to state key;
• storefor store initialization.

• components对于不知道 Redux 的“愚蠢”React 组件；
• containers用于连接到 Redux 的“智能” React 组件；
• actions对于所有动作创建者，其中文件名对应于应用程序的一部分；
• reducers对于所有的reducer，文件名对应状态键；
• store用于商店初始化。

This works well for small and mid-level size apps.

这适用于中小型应用程序。

When you want to go more modular and group related functionality together, Ducksor other ways of grouping functionality by domainis a nice alternative way of structuring your Redux modules.

当您想要更加模块化并将相关功能组合在一起时，Ducks或其他按域对功能进行分组的方法是构建 Redux 模块的一种不错的替代方法。

Ultimately choose whatever structure works best for you. There is no way Redux authors can know what's convenient for you better than you do.

最终选择最适合您的结构。Redux 作者不可能比你更了解什么对你来说更方便。

回答by Kloar

This is more a question about best practices / code style, and there is no clear answer. However, a very neat style was proposed in the React redux boilerplateproject. It's very similar to what you currently have.

这更多是关于最佳实践/代码风格的问题，并没有明确的答案。然而，在React redux 样板项目中提出了一种非常简洁的风格。它与您目前拥有的非常相似。

./react-redux-universal-hot-example
├── bin
├── src
│   ├── components // eg. import { InfoBar } from '../components'
│   │   ├── CounterButton
│   │   ├── GithubButton
│   │   ├── InfoBar
│   │   ├── MiniInfoBar
│   │   ├── SurveyForm
│   │   ├── WidgetForm
│   │   └── __tests__
│   ├── containers // more descriptive, used in official docs/examples...
│   │   ├── About
│   │   ├── App
│   │   ├── Home
│   │   ├── Login
│   │   ├── LoginSuccess
│   │   ├── NotFound
│   │   ├── RequireLogin
│   │   ├── Survey
│   │   ├── Widgets
│   │   └── __tests__
│   │       └── routes.js // routes defined in root
│   ├── redux
│   │   ├── init.js
│   │   ├── middleware
│   │   │   └── clientMiddleware.js  // etc
│   │   └── modules // (action/creator/reducer/selector bundles)
│   │       ├── auth.js
│   │       ├── counter.js
│   │       ├── reducer.js  
│   │       ├── info.js
│   │       └── widgets.js
│   ├── server
│   │   ├── middleware
│   │   └── actions // proxy to separate REST api...
│   └── utils
│   │   ├── validationUtility.js // utility only (component-level definitions inside respective dir)
│       └── createDevToolsWindow.js  // etc
├── static
│   ├── dist
│   └── images
└── webpack

回答by dakt

I prefer keeping smart and dumb components in the same file, but use default export for smart component and export for presentation/dumb components. This way you can reduce file noise in your directory structure. Also group your components by "View" i.e. (Administration => [admin.js, adminFoo.js, adminBar.js], Inventory => [inventory.js, inventoryFoo.js, inventoryBar.js], etc).

我更喜欢将智能和哑组件保存在同一个文件中，但对智能组件使用默认导出，对演示/哑组件使用导出。通过这种方式，您可以减少目录结构中的文件噪音。还可以按“视图”对组件进行分组，即（管理 => [admin.js、adminFoo.js、adminBar.js]、库存 => [库存.js、库存Foo.js、库存Bar.js] 等）。

回答by w00t

I have no strong opinion about the component directories, but I like putting the actions, constants and reducers together:

我对组件目录没有强烈的看法，但我喜欢将操作、常量和减速器放在一起：

state/
  actions/
    index.js
    ...
  constants.js
  reducers.js

I alias statewith with webpack so in the container components I can import {someActionCreator} from 'state/actions';.

我state用 webpack别名，所以在容器组件中我可以import {someActionCreator} from 'state/actions';。

This way, all the stateful code in the app resides in a single place.

这样，应用程序中的所有有状态代码都位于一个地方。

Note that reducers.jscould be split into multiple files simply by making a reducers/directory like actions/and you wouldn't have to change any import statements.

请注意，reducers.js只需创建一个reducers/目录即可将其拆分为多个文件，actions/而您不必更改任何导入语句。

回答by luk_z

In Redux you have one entry point for your actions (actions/ folder) and an entry point for the reducers (reducers/ folder).

在 Redux 中，你有一个动作入口点（actions/ 文件夹）和一个减速器入口点（reducers/ 文件夹）。

If you go with domain-based code structure you simplify domain/feature implementation and maintenance... on the other hand you are complicating component dependencies and app state/logic maintenance.

如果您使用基于域的代码结构，您可以简化域/功能实现和维护……另一方面，您正在使组件依赖项和应用程序状态/逻辑维护复杂化。

Where are you gonna put reusable components? inside feature/domain folder? so if you need a reusable component from other feature/domain you need to create a dependency between domains? mmh not so good for large app!

你要把可重用的组件放在哪里？在功能/域文件夹中？因此，如果您需要来自其他功能/域的可重用组件，您需要在域之间创建依赖关系吗？嗯对大型应用程序不太好！

When you have to combine reducers, domain-code-structure takes away what it gave you previously.

当你必须结合 reducer 时，域代码结构会带走它之前给你的东西。

You are only creating single redux modules for each domain/feature. domain-code-structure should be good in some/most cases, but this is not Redux.

您仅为每个域/功能创建单个 redux 模块。域代码结构在某些/大多数情况下应该是好的，但这不是 Redux。

回答by leLabrador

I have a boilerplate with react, redux folder structure and it's being used for many company projects. You can check it out here: https://github.com/nlt2390/le-react-redux-duck

我有一个带有 react、redux 文件夹结构的样板，它被用于许多公司项目。你可以在这里查看：https: //github.com/nlt2390/le-react-redux-duck