Обратите внимание, что эта статья устарела, я решил создать новую с лучшей структурой и с учетом автономных компонентов: https://medium.com/@marekpanti/angular-standalone-architecture-b645edd0d54a
Angular — это самоуверенная платформа, и очень важно понимать, как ее следует использовать правильно и красиво. У нас есть набор правил, которые следует применять, чтобы облегчить себе жизнь и, конечно же, облегчить ее своим коллегам.
Когда мы создаем новое приложение, мы всегда должны пройти через:
- Насколько большим будет приложение через 2 или 3 года?
- Будет ли у нас монорепозиторий
- Есть ли в нашем приложении какие-то инструменты или оно может стать частью другого приложения в будущем
- Независимо от того, создаем ли мы его для широкой публики и, следовательно, нам нужно определенное состояние, или мы создаем его как внутреннее приложение (где мы в основном заботимся о функциях, функциональности и т. д.)
Каждый из его пунктов имеет некоторые дополнительные моменты, о которых следует подумать, например: если наше приложение может быть в монорепозитории, это означает, что авторизация, общие компоненты и часть приложения с функциями будут размещены в библиотеках -> так мы должны уважать эту архитектуру с самого начала.
- Представьте, что ваше приложение Angular уже находится в монорепозитории
Исходя из своего опыта, я обнаружил, что многие приложения в конечном итоге оказываются в монорепозитории или в виде микроприложений чего-то большего, и часто требуется до трех месяцев только на то, чтобы внести это изменение, чтобы иметь возможность раскрыть спагетти модулей. и адаптировать его к новой структуре,
Как следствие, я предлагаю начать ваше простое угловое приложение со следующими модулями в начале:
- Общий
- Состояние
- Авторизация
- Функции
Общие модули:
В общих модулях у нас будут наши директивы, пайпы, общие сервисы, общие компоненты, возможно, наша система дизайна и т. д. Теперь эта часть немного сложна. Потому что в зависимости от того, насколько велика ваша общая папка, вы можете выбрать какую-то модульность. Основываясь на теме в смысле того, как часто вы используете определенную общую функцию в своем приложении — вам нужно решить, какая функция должна быть в основном общем модуле, иметь собственный модуль или быть в чем-то конкретном — например, в модуле материала angular. для экспорта элементов.
Штат:
Состояние нашего приложения — это место, где хранятся данные,
Здесь мы определяем структуру данных внешнего интерфейса, и в зависимости от сложности у нас есть:
- Наш сервис данных, который мы просто вызываем, чтобы показать какие-то данные — а это значит, что каждый раз, когда компонент запускается, данные вызываются!
- Мы храним наши данные в Observable и создаем примитивную систему состояний на некоторых специфических функциях, но это должно быть сделано красиво — я не рекомендую это делать.
- Или мы можем использовать некоторые существующие системы состояний, такие как NGRX.
В основном состояние должно иметь службу или селекторы для каждого фрагмента данных, которые будут называться Фасадной службой компонента.
Авторизация:
По сути, авторизация — это функциональный модуль, но я рекомендую иметь его в виде отдельного блока в нашем приложении из-за будущего перехода на монорепозиторий NX —> тогда вы просто скопируете модуль в библиотеку и сможете использовать другие библиотеки.
Возможности:
Функция должна быть лениво загруженным модулем с фасадной службой, которая вызывает определенный метод из нашего модуля состояния для отображения данных.
В функции мы используем компоненты родитель-потомок. Это представляет собой пример хорошей гранулированной архитектуры.
Другие важные правила:
Кроме того, при создании углового приложения с учетом этой архитектуры также важно учитывать сложность каждого компонента и чистоту функций. Пока мы рассмотрим только основы:
- Вы должны соблюдать максимальный размер 300–400 строк на компонент.
- Вы должны настроить красивее и линтер.
- У вас не должно быть никакой логики данных в ваших компонентах
- Ваши методы не должны иметь побочных эффектов.
- Если вы не используете разработку через тестирование, полезно, по крайней мере, написать свои методы до того, как вы начнете программировать.
В заключение:
В заключение я хотел бы подчеркнуть важность заботы о кодовой базе. Самый ответственный момент в начале. Минимум, что мы можем сделать, это настроить наше приложение, так как оно уже выглядит как монорепозиторий.
Если вас интересуют подробности и способы организации ваших компонентов, ознакомьтесь с моей статьей.