Структура каталогов приложения ReactJS Flux

В настоящее время моя команда работает над большим приложением, написанным на ReactJS с использованием архитектуры Flux от Facebook. Сейчас он все еще находится в зачаточном состоянии, но очень скоро он станет большим. Он будет иметь более 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 и чат) имеют архитектуру, подходящую для небольших приложений, но как только количество этих хранилищ, компонентов и действий увеличивается, ими становится все труднее управлять.

Заранее спасибо.


reactjs directory-structure reactjs-flux
person hvkale    schedule 29.04.2015    source источник
comment
Если компонент достаточно общий и достаточно многоразовый, разбейте его на отдельный модуль npm. Если вы щедры, откройте исходный код и разместите его на react-components.com.   -  person Joe Frambach    schedule 30.04.2015
comment
Я думаю, что это путь для больших приложений. Но ваши модули могут быть слишком маленькими. Мое приложение в настоящее время упорядочено по типу, как показано в ответе @fisherwebdev и каждом отдельном примере потока, но я считаю, что это не очень хорошо масштабируется. У меня уже 25 магазинов в папке store. Я планирую «упорядочить по функциям» вместо «упорядочить по типу», каждая из этих функций на самом деле будет небольшим «приложением», которое будет подключаться к «базовому» приложению. Каждый из них должен зависеть только от основного модуля. Хотя это всего лишь идея. Еще не разработан.   -  person RoryKoehein    schedule 01.05.2015
comment
@RoryKoehein ты придумал что-то еще, чтобы попробовать? Хотя я думаю, что это правильный подход. Вот как мы это сделали, за исключением того, что мы также снова упорядочили по типу внутри функции, что привело к огромной загрузке дополнительных папок с несколькими файлами.   -  person froginvasion    schedule 19.05.2016
comment
@froginvasion да, мы наконец сделали это в прошлом месяце. Мы переместили все приложение в основную папку и теперь перемещаем модули один за другим. Мы также упорядочиваем модули по типу, что, я согласен, кажется несколько чрезмерным. Каждый модуль имеет от 1 до 5 накопителей атм. Модули можно исключить из приложения, удалив их из точки входа приложения, где они импортируются и загружаются. Они зависят только от ядра. Когда ядру или другим модулям необходимо использовать код из модуля, они должны проверить, доступен ли модуль через фасад (модули также совместно используются на context в представлениях React).   -  person RoryKoehein    schedule 19.05.2016

Ответы (2)


arrow_upward
20
arrow_downward

Обычная структура каталогов выглядит примерно так:

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 между хранилищами и представлением запроса или «разделом», как в этом примере.

И на самом деле вам просто нужно делать то, что подходит для вашего приложения. Это не догма. Поток данных, инверсия управления и разделение хранилищ — это гораздо более важные идеи, чем то, как вы организуете свои файлы.

person fisherwebdev    schedule 01.05.2015
comment
Действительно, другие вещи важнее структуры папок. С другой стороны, структура папок может дать вам (или будущим разработчикам) очень хорошее представление о том, что происходит. Я почти думаю, что модели папок/подпапок/файлов недостаточно, и, возможно, будет полезна IDE, обеспечивающая большую гибкость (например, граф папок вместо дерева папок). - person Panagiotis Panagi; 09.12.2015
comment
также поручился здесь: структура папок - person Sida Zhou; 12.01.2016
comment
Так что подождите... всякий раз, когда вы используете действие, вы должны импортировать "../../someActions"? То же самое, если вам нужна какая-либо из ваших утилит, вам придется пройтись по нескольким папкам. Конечно, она уже намного более плоская, чем моя структура папок. - person froginvasion; 19.05.2016

arrow_upward
0
arrow_downward

Я также изо всех сил пытался выбрать начальную структуру для большого приложения. Я получил структуру, очень похожую на вашу, после того, как провел время с приложением, разделенным на папки в зависимости от роли потока (например, действия, хранилища, константы и т. д.).

Во-первых, если вы используете что-то вроде Broswerify, относительный путь для ваших вызовов require прекрасен. Во-вторых, отсутствие необходимости искать файлы в разных папках, когда вы работаете над определенным компонентом, значительно экономит время.

Для сквозных задач, таких как диспетчер, вспомогательные функции, загрузчик и т. д., у меня есть эквивалентный модуль приложения. Всегда кажется, что для каждого файла, с которым я работаю, есть разумное место, и новые разработчики не пытаются найти коррелированные файлы (проблема, когда ваши модули могут иметь общий префикс).

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

person Michael Ross    schedule 17.06.2015