Как структурировать компоненты/контейнеры 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.