Обратите внимание, что эта статья устарела, я решил создать новую с лучшей структурой и с учетом автономных компонентов: https://medium.com/@marekpanti/angular-standalone-architecture-b645edd0d54a

Angular — это самоуверенная платформа, и очень важно понимать, как ее следует использовать правильно и красиво. У нас есть набор правил, которые следует применять, чтобы облегчить себе жизнь и, конечно же, облегчить ее своим коллегам.

Когда мы создаем новое приложение, мы всегда должны пройти через:

  • Насколько большим будет приложение через 2 или 3 года?
  • Будет ли у нас монорепозиторий
  • Есть ли в нашем приложении какие-то инструменты или оно может стать частью другого приложения в будущем
  • Независимо от того, создаем ли мы его для широкой публики и, следовательно, нам нужно определенное состояние, или мы создаем его как внутреннее приложение (где мы в основном заботимся о функциях, функциональности и т. д.)

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

  1. Представьте, что ваше приложение Angular уже находится в монорепозитории

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

Как следствие, я предлагаю начать ваше простое угловое приложение со следующими модулями в начале:

  1. Общий
  2. Состояние
  3. Авторизация
  4. Функции

Общие модули:

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

Штат:

Состояние нашего приложения — это место, где хранятся данные,

Здесь мы определяем структуру данных внешнего интерфейса, и в зависимости от сложности у нас есть:

  • Наш сервис данных, который мы просто вызываем, чтобы показать какие-то данные — а это значит, что каждый раз, когда компонент запускается, данные вызываются!
  • Мы храним наши данные в Observable и создаем примитивную систему состояний на некоторых специфических функциях, но это должно быть сделано красиво — я не рекомендую это делать.
  • Или мы можем использовать некоторые существующие системы состояний, такие как NGRX.

В основном состояние должно иметь службу или селекторы для каждого фрагмента данных, которые будут называться Фасадной службой компонента.

Авторизация:

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

Возможности:

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

В функции мы используем компоненты родитель-потомок. Это представляет собой пример хорошей гранулированной архитектуры.

Другие важные правила:

Кроме того, при создании углового приложения с учетом этой архитектуры также важно учитывать сложность каждого компонента и чистоту функций. Пока мы рассмотрим только основы:

  • Вы должны соблюдать максимальный размер 300–400 строк на компонент.
  • Вы должны настроить красивее и линтер.
  • У вас не должно быть никакой логики данных в ваших компонентах
  • Ваши методы не должны иметь побочных эффектов.
  • Если вы не используете разработку через тестирование, полезно, по крайней мере, написать свои методы до того, как вы начнете программировать.

В заключение:

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

Если вас интересуют подробности и способы организации ваших компонентов, ознакомьтесь с моей статьей.