Как структурировать компоненты/контейнеры Redux

Я использую 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

затем, в папке containers, у меня есть один контейнер на страницу, это единственные, которые я фактически подключаю к Redux:

containers/
  HomePageApp.js
  EpisodePageApp.js
  ...

и тогда действия по одному на каждый верхний компонент, а не по одному на страницу, поэтому в контейнере страницы чтобы подключиться к Redux, я передаю все действия компонентов, используемых на этой странице. Например:

actions/
  Player.js
  Episode.js
  ...

правильно ли я это делаю? Я не нашел много информации об этом в гугле, и те, которые я нашел, я думаю, что они ограничены небольшими проектами.

спасибо!

5 ответов


в официальных примерах у нас есть несколько каталогов верхнего уровня:

  • components на "тупой" реагируют компоненты, не знающие о Redux;
  • containers для" умных " компонентов React, подключенных к Redux;
  • actions для всех создателей действий, где имя файла соответствует части приложения;
  • reducers для всех редукторов, где имя файла соответствует ключу состояния;
  • store для магазина инициализация.

это хорошо работает для малого и среднего размера приложений.

если вы хотите перейти на более модульную и групповую функциональность вместе,утки или другие способы группирования на домен - хороший альтернативный способ структурирования ваших модулей Redux.

в конечном счете выбрать любую структуру работает лучше всего для вас. Авторы Redux никоим образом не могут знать, что удобно для вас лучше, чем вы делать.


это больше вопрос о лучших практиках / стиле кода, и нет четкого ответа. Тем не менее, очень аккуратный стиль был предложен в React redux boilerplate. Это очень похоже на то, что у вас сейчас есть.

./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

Я предпочитаю хранить интеллектуальные и немые компоненты в одном файле, но использовать экспорт по умолчанию для интеллектуального компонента и экспорт для презентации/немых компонентов. Таким образом, вы можете уменьшить шум файлов в вашей структуре каталогов. Также сгруппируйте свои компоненты по "View", т. е. (Administration => [admin.js, adminFoo.js, adminBar.js], Inventory => [инвентарь.js, inventoryFoo.js, inventoryBar.в JS] и др.).


у меня нет сильного мнения о каталогах компонентов, но мне нравится объединять действия, константы и редукторы:

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

Я псевдоним state С помощью webpack, поэтому в компонентах контейнера я могу import {someActionCreator} from 'state/actions';.

таким образом, весь код состояния в приложение находится в одном месте.

отметим, что reducers.js можно разделить на несколько файлов, просто сделав


в Redux у вас есть одна точка входа для ваших действий (действия/ папка) и точка входа для редукторов (редукторы/ папка).

Если вы идете с доменной структурой кода, вы упрощаете реализацию и обслуживание домена/функции... с другой стороны, вы усложняете зависимости компонентов и обслуживание состояния/логики приложения.

где вы собираетесь разместить многоразовые компоненты? внутри папки функции / домена? поэтому, если вам нужен многоразовый компонент из другого функция / домен вам нужно создать зависимость между доменами? mmh не так хорошо для большого приложения!

когда вам нужно объединить редукторы, domain-code-structure забирает то, что он дал вам ранее.

вы создаете только отдельные модули redux для каждого домена / функции. домен-код-структура должна быть хорошей в некоторых / большинстве случаев, но это не Redux.