Структура каталога приложений 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. Всегда кажется, что есть разумное место для каждого файла, с которым я работаю, и новые разработчики не пытаются найти коррелированные файлы (проблематично, когда ваши модули могут использовать префикс).

С момента переключения я не оглядывался назад.