Структура файлов


Существует ли рекомендованный способ структурировать проекты React?

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


Группирование по функции или маршруту.

Одним из распространенных способов структурирования проектов является размещение CSS, JS и тестов вместе внутри папок, сгруппированных по функции или маршруту.


Код
    
    common/
      Avatar.js
      Avatar.css
      APIUtils.js
      APIUtils.test.js
    feed/
      index.js
      Feed.js
      Feed.css
      FeedStory.js
      FeedStory.test.js
      FeedAPI.js
    profile/
      index.js
      Profile.js
      ProfileHeader.js
      ProfileHeader.css
      ProfileAPI.js
    

Определение «функция» не является универсальным, и вся детализация остается за вами. Если вы не можете определить список папок верхнего уровня, вы можете спросить пользователей вашего продукта, из каких основных частей он состоит, и использовать их мысленную модель в качестве плана.


Группирование по типу файлов.

Другим популярным способом структурирования проектов является группировка похожих файлов, например:


Код
    
    api/
      APIUtils.js
      APIUtils.test.js
      ProfileAPI.js
      UserAPI.js
    components/
      Avatar.js
      Avatar.css
      Feed.js
      Feed.css
      FeedStory.js
      FeedStory.test.js
      Profile.js
      ProfileHeader.js
      ProfileHeader.css
    

Некоторые люди также предпочитают идти дальше и поместить компоненты в различные папки в зависимости от их роли в приложении. Например, Atomic Design - это методология проектирования, построенная на данном принципе. Помните, что часто полезнее рассматривать такие методологии как полезные примеры, а не как строгие правила.


Избежание большой вложенности.

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


Не переусердствуйте!

Если вы только начинаете проект, не тратьте более пяти минут на выбор файловой структуры. Выберите любой из вышеуказанных подходов (или придумайте свой собственный) и начните писать код! Вероятно, вы захотите переосмыслить структуру, написав какой-нибудь реальный код.

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

На практике по мере своего роста проекты часто используют сочетание обоих вышеупомянутых подходов. Поэтому выбор «правильного» в самом начале не очень важен.