Прежде всего: я создал несколько приложений Enterprise, используя Angular, и видел вещи, которые работают, и вещи, которые я хотел бы никогда не пробовать.Хорошая новость заключается в том, что инструменты рефакторинга / dev настолько хороши в наши дни, что вы можете переключать структуру проекта в середине проекта, когда обнаружите, что он стал неуправляемым.Единственная плохая новость: это создаст кошмары слияния, которые проверит ваш git-fu.
В руководстве по стилю упоминается папок по функции , что звучит так, как вы уже делаете.Я бы придерживался того, что вы сейчас делаете, и это должно масштабироваться.У вас уже есть опыт работы с ним, он работает, и пробовать что-то совершенно другое, когда вы впервые запускаете более крупное приложение, звучит как рецепт для катастрофы.
Главное, чего следует избегать, - это иметь излишне сложную структуру папок, котораяна самом деле не отражает структуру вашего приложения.Например, если у вас есть раздел управления профилями, не помещайте его в /dashboard/user/components/profile/edit или что-то подобное, если только он фактически не имитирует структуру вашего приложения.Это кажется очевидным, но люди делают это постоянно, и это делает ваш код менее доступным для обнаружения.Я думаю, что это подпадает под концепцию LIFT :
Do структурировать приложение так, чтобы вы могли быстро находить код, быстро идентифицировать код,сохраните самую плоскую структуру, какую только можете, и попытайтесь быть СУХОЙ.
Do определите структуру, чтобы следовать этим четырем основным рекомендациям, перечисленным в порядке важности.
Почему? LIFT Обеспечивает согласованную структуру, которая хорошо масштабируется, является модульной и упрощает повышение эффективности работы разработчика за счет быстрого поиска кода.Чтобы подтвердить свою интуицию о конкретной структуре, спросите: могу ли я быстро открыть и начать работать со всеми соответствующими файлами для этой функции?
Далее следует упомянуть о сохранении структуры плоских папок.возможно:
Do сохранять структуру плоской папки как можно дольше.
Рассмотрим создание подпапок, когда папка достигает семиили больше файлов.
Попробуйте настроить IDE для скрытия отвлекающих, не относящихся к делу файлов, таких как сгенерированные файлы .js и .js.map.
Почему? Никто не хочет искать файл по семи уровням папок.Плоская структура легко сканируется.
Это один из самых важных моментов с точки зрения крупных проектов.Когда вы работаете над приложением с 20 модулями, излишне сложная структура папок вызывает легкое раздражение.Когда вы получите 150 модулей, вы будете инстинктивно съеживаться, открывая IDE. общие структурные рекомендации являются хорошей отправной точкой для проекта и демонстрируют, когда следует соблюдать /feature/ против использования папок подфункций.
Относительно модуля на компонент:
Do создать модуль NgModule для каждой области функций.
Почему? NgModules облегчают ленивую загрузку маршрутизируемых функций.
Почему? NgModules упрощают изоляцию, тестирование и повторное использование функций.
Вы можете расширить это, чтобы сказать, что вы должны создать модуль для каждогокомпонент, но я бы на самом деле избегал этого, если у вас нет особой необходимости для данного модуляОпять же - по моему опыту, создание накладных расходов для вас становится еще больше громоздким, чем больше ваш проект.Те вещи, которые кажутся слегка раздражающими в небольших проектах, становятся большими кошмарами в крупных проектах.
Последнее замечание: будьте готовы к изменениям.Вы и ваши коллеги можете потратить неделю на планирование структуры вашего проекта, но только после того, как вы начнете использовать его, вы почувствуете, что это неправильно.Трудно сделать все на 100% правильно с первой попытки.Проще медленно повторять, пока не достигнете чего-то, что почти идеально.
Мои проекты обычно выглядят примерно так:
app/
| core/
| | constants/ // Keep all constants in a single place and avoid magic IDs/strings.
| | |-http-status-codes.enum.ts
| | guards/ // I like to group my guards in a single place
| | http-interceptors/ // Same with interceptors
| | pipes/ // Some pipes might be section-specific but they are usually core
| | services/ // Core services. Utilities, error handling, etc.
| | |-error-handler.service.ts
| | validators/
| section1/
| | models/
| | sub1/ // I try not to nest too deeply
| | |-sub1.component.ts|html|css|spec.ts
| |-section1-routing.module.ts // Routing by section
| |-section1.component.ts|html|css|spec.ts
| |-section1.module.ts // Module per section for lazy loading, etc.
| |-section1.service.ts // Section-specific service
| shared/
| | models/
| | app-modal-dialog/
| | my-awesome-widget/
| | some-custom-input/
|-app.component.ts|html|css|spec.ts
|-app.module.ts
|-app-routing.module.ts
assets/ // Static content
environments/
|-environment.x.ts // Stripe public keys, etc.
Опять же - это вполне соответствует руководству по стилю .