В документации Angular указано, что структура папок приложения должна соответствовать LIFT:

Https://angular.io/guide/styleguide#lift

Я здесь, чтобы бросить этому вызов. Я работал во многих проектах Angular, и каждый раз, когда появлялся проект с очень «плоской» структурой, я, как правило, работал медленнее, и поиск компонентов становился сложнее. На плоских проектах заметна познавательная нагрузка. Очень сложно открыть папку src/app и получить 50 папок и файлов. Трудно понять, как все файлы и папки связаны друг с другом.

Вы можете возразить, что можете использовать такие инструменты, как Дерево компонентов Angular Augury, чтобы по-настоящему увидеть структуру приложения. Однако это не очень хорошо. Даже если бы он был идеальным, это потребовало бы alt-tabbing входа и выхода из консоли Augury Developer и вашей IDE, что, по иронии судьбы, увеличивает когнитивную нагрузку и ухудшает рабочий процесс.

Официальные документы по Angular говорят:

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

Вики-статья (также известная как закон Миллера), упомянутая в документации Angular, утверждает, что количество объектов, которые средний человек может хранить в рабочей памяти, составляет 7 ± 2. При работе в команде вполне вероятно, что некоторые люди будут связаны попасть в нижнюю часть этого спектра, включая меня.

Я не стыжусь признаться, что мне трудно читать код, который требует, чтобы читатель отслеживал 4 переменные одновременно. Я уверен, что я не одинок в этом. Это также напрямую влияет на структуру папок.

Если бы вам была предоставлена ​​полная плоская структура, как вы должны знать, как они соотносятся друг с другом, без использования Angular Augury (объяснено выше) или погружения в то, как используется каждый компонент? Это нормально для разработчиков, которые знакомы с проектом, но для новых разработчиков это оказывает им огромную медвежью услугу.

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

Что у нас есть сейчас

Официальная инструкция плоская, но есть неглубокое гнездование. Кажется, существует искусственное ограничение уровней вложенности

Я считаю, что пример в официальной документации слишком упрощен. В действительности у вас будут компоненты внутри компонентов внутри компонентов и т. Д.

Этот плоский подход упрощает рефакторинг и перемешивание компонентов, но я цитирую Роберта К. Мартина:

Действительно, соотношение времени, затрачиваемого на чтение и на запись, намного превышает 10: 1.

Https://www.goodreads.com/quotes/835238-indeed-the-ratio-of-time-spent-reading-versus-writing-is

Поэтому следует писать и проектировать код, который легко читать.

Предложение

Следуйте DOM

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

Преимущества:

  • Вы ограничены областью вашей работы.
    Это становится все более важным по мере роста вашего приложения.
  • Пониженная когнитивная нагрузка.
    Средний человек может хранить в рабочей памяти 7 ± 2 объектов. Меньше файлов и папок, которые нужно хранить в мозгу одновременно.
  • Легко визуализировать вашу работу
    Вложенная файловая структура напрямую соответствует физическому миру, что упрощает взаимодействие. Это позволяет новичкам в проекте легко начать работу, а ветеранам, возвращающимся в проект, легко повторно ознакомиться.

Локальные модули NgModules

Все ненавидят ужасный монолитный AppModule, который, как правило, делают новые разработчики Angular. По мере взросления Angular-разработчики видят ценность в меньшем и меньшем NgModules. Подводя итоги игры:

Создайте локальный модуль NgModule для каждого вложенного уровня, если внутри этого компонента есть дочерние компоненты.

Примечание: Younes написал очень хорошую статью, похожую на эту. Они называют это однокомпонентным угловым модулем (SCAM): https://medium.com/wishtack/your-angular-module-is-a-scam-b4136ca3917b

Преимущества:

  • Это улучшает инкапсуляцию.
    Вы можете решить, какие компоненты экспортировать за пределы.
    Родительский компонент может просто импортировать дочерний NgModule без какой-либо конфигурации.
    Вы знаете, знаете ли вы, что изменить компонент, это не повлияет ни на что за его пределами.
  • Это значительно упрощает тестирование.
    Вы уверены, что все зависимости вашего испытуемого находятся в этом крошечном NgModule, а не где-либо еще.
  • Больше прозрачности.
    Вы можете быть уверены, что область, в которой вы работаете, состоит только из компонентов и служб, определенных в локальном NgModule. Это противоположно монолитному AppModule, где это высокий хаос и ограниченное знание того, как все они взаимодействуют вместе.
  • Пониженная когнитивная нагрузка.
    Среднестатистический человек может удерживать в рабочей памяти 7 ± 2 объектов. С меньшими NgModules, естественно, легче работать.

Нет правила, когда и когда не использовать NgModule. NgModule - это просто набор компонентов и сервисов. Используйте NgModules как можно больше.

Резюме

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

Следуйте за мной на GitHub: https://github.com/dolanmiu