{"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":[]}