Структура каталога приложений ReactJS Flux
Моя команда в настоящее время работает над большим приложением, написанным в ReactJS, используя архитектуру Facebook Flux. Сейчас он все еще находится в зачаточном состоянии, но он скоро вырастет. Он будет иметь более 50 представлений небольших компонентов, множество действий, магазинов и создателей действий.
В настоящее время наша структура каталогов выглядит как
App
|___ module_1
| |___ components
| | |___ component1.react.js
| | |___ component2.react.js
| |___ module1ActionCreators.js
| |___ module1Constants.js
| |___ module1store.js
|
|___ module_2
|___ ... (same structure as above)
Одной из проблем, связанных с этим подходом, является то, что папки module_x будут становиться все более значительными, поскольку это приложение растет.
Есть ли у кого-нибудь возможность поделиться тем, как они структурировали свое приложение? По нашему опыту, приложения для приложений Facebook (todo и chat) имеют архитектуру, подходящую для небольших приложений, но как только эти магазины, компоненты и действия растут в количестве, что становится сложнее в управлении.
Спасибо заранее.
Ответы
Ответ 1
Обычная структура каталогов выглядит примерно так:
js
├── AppBootstrap.js
├── AppConstants.js
├── AppDispatcher.js
├── actions
│ ├── AppActions.js
│ ├── FriendActions.js
│ └── PhotoActions.js
├── components
│ ├── AppRoot.react.js
│ ├── friends
│ │ ├── Friend.react.js
│ │ ├── FriendList.react.js
│ │ └── FriendSection.react.js // a querying-view, AKA controller-view
│ └── photos
│ ├── Photo.react.js
│ ├── PhotoCategoryCard.react.js
│ ├── PhotoCategoryCardTitle.react.js
│ ├── PhotoGrid.react.js
│ └── PhotoSection.react.js // another querying-view
├── stores
│ ├── FriendStore.js
│ ├── PhotoStore.js
│ └── __tests__
│ ├── FriendStore-test.js
│ └── PhotoStore-test.js
└── utils
├── AppWebAPIUtils.js
├── FooUtils.js
└── __tests__
├── AppWebAPIUtils-test.js
└── FooUtils-test.js
Каталог css обычно выглядит как зеркало каталога компонентов с одним файлом css для каждого компонента. Некоторые люди в наши дни предпочитают делать все свои стили, встроенные в компонент, однако.
Не переутомляйте все это - между магазинами и запросом-представлением или "секцией" не всегда есть 1:1, как в этом примере.
И действительно, вам просто нужно делать то, что подходит для вашего приложения. Это не догма. Материал потока данных, инверсия управления и развязка магазинов - это гораздо более важные идеи, чем то, как вы организуете свои файлы.
Ответ 2
Я также боролся с выбором исходной структуры для большого приложения. Я закончил работу с очень похожей структурой, после того как потратил время на приложение, разделенное на папки на основе роли потока (т.е. Действия, магазины, константы и т.д.).
Во-первых, если вы используете что-то вроде Broswerify, относительный путь к вашим вызовам требует прекрасного. Во-вторых, не нужно выслеживать файлы в разных папках, когда вы работаете над конкретным компонентом, это огромная экономия времени.
Для перекрестных проблем, таких как диспетчер, вспомогательные функции, bootstrapper и т.д., у меня есть эквивалентный модуль App. Всегда кажется, что есть разумное место для каждого файла, с которым я работаю, и новые разработчики не пытаются найти коррелированные файлы (проблематично, когда ваши модули могут использовать префикс).
С момента переключения я не оглядывался назад.
