{"componentChunkName":"component---src-templates-docs-js","path":"/docs/faq-structure.html","result":{"data":{"markdownRemark":{"html":"\n

Единого мнения не существует. Однако, есть несколько популярных подходов, которые вы можете рассмотреть.

\n

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

\n

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

\n
common/\n  Avatar.js\n  Avatar.css\n  APIUtils.js\n  APIUtils.test.js\nfeed/\n  index.js\n  Feed.js\n  Feed.css\n  FeedStory.js\n  FeedStory.test.js\n  FeedAPI.js\nprofile/\n  index.js\n  Profile.js\n  ProfileHeader.js\n  ProfileHeader.css\n  ProfileAPI.js
\n

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

\n

Группировка по типу файла

\n

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

\n
api/\n  APIUtils.js\n  APIUtils.test.js\n  ProfileAPI.js\n  UserAPI.js\ncomponents/\n  Avatar.js\n  Avatar.css\n  Feed.js\n  Feed.css\n  FeedStory.js\n  FeedStory.test.js\n  Profile.js\n  ProfileHeader.js\n  ProfileHeader.css
\n

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

\n

Избегайте чрезмерной вложенности

\n

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

\n

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

\n

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

\n

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

\n

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

","frontmatter":{"title":"Структура файлов","next":null,"prev":null},"fields":{"path":"content/docs/faq-structure.md","slug":"docs/faq-structure.html"}}},"pageContext":{"slug":"docs/faq-structure.html"}},"staticQueryHashes":[]}