Как организовать проекты Angular? В следующей статье собраны и представлены 5 практических советов по управлению проектами Angular. Надеюсь, она будет полезна всем! 
Вход в курс повышения квалификации по интерфейсу (vue): введите обучение
По мере выпуска новых функций Web apps становятся все больше и больше. В процессе DevOps компании подобные изменения релизов происходят каждый день. [Рекомендуемые связанные учебные пособия: «учебник по Angular»]
В таком быстром цикле выпуска код может быстро стать громоздким. Особенно проекты, разработанные на основе JavaScript , такие как NextJS или Angular.
Вот наши 5 лучших практик управления проектами Angular для максимальной читаемости, удобства сопровождения и масштабируемости.
Многие отдельные ядра приложений представляют собой базы кода с раздутыми классами. По своей природе эти раздутые программы сложно поддерживать. Они хрупкие в том смысле, что изменение одной строки кода может иметь катастрофические последствия для всей программы. Принцип единой ответственности может предотвратить эти проблемы.
Принцип единой ответственности означает, что компонент имеет одну и только одну функцию.
Создание приложений с использованием этого подхода приводит к созданию модульной структуры, в которой приложение объединяется посредством этих блоков кода.
Использование этого подхода может сделать программы более читабельными и удобными в сопровождении. Он также может легко найти определенные функции в приложении.
Чтобы убедиться, что ваш код соответствует этому требованию, задайте себе вопрос:这代码是干什么的？ Если ваш ответ содержит ключевое слово and , вам необходимо выполнить рефакторинг кода в код с одной ответственностью.
Создание и расширение приложений Angular — это постоянная работа. Со временем организация ваших проектов по принципу единой ответственности сделает ваши приложения чистыми, читаемыми и удобными в обслуживании.
Модули в Angular — это реализация единого принципа. В Angular каждый модуль представляет собой отдельный и независимый функционал.
Angular предоставляет несколько модулей типов, позволяющих указать, как их логически группировать или организовывать.
Основной
Модуль Core — это NgModule , который используется для создания экземпляра приложения и загрузки основных функций для глобального использования.
Следовательно, любая одноэлементная служба должна быть реализована в основном модуле. Шапка, подвал или панель навигации являются модулями этого типа.
Все службы (службы-одиночки), имеющие один и только один экземпляр для каждого приложения, должны быть реализованы в основном модуле. Например, служба аутентификации или служба пользователя.
Особенность
Функциональные модули представляют собой код, который создает функциональность приложения. Например, в приложении для онлайн-покупок у нас будет функция добавления товаров в корзину и отдельный модуль для оплаты.
Общий
Общие модули состоят из модулей, которые можно комбинировать для создания новых функций. Например, функцию поиска можно использовать для нескольких функций платформы.
Такое структурирование кода упрощает поиск и увеличивает вероятность повторного использования кода.
Файлы стилей могут быстро стать дезорганизованными, если они не соответствуют общей структуре. Общий шаблон передового опыта 7-1 , который использует 7 папок и 1 файл, как показано ниже:
App — основная папка проекта
Abstract — абстрактный раздел, содержащий все переменные, примеси и подобные компоненты.
Ядро — содержит макет, сброс и шаблонный код для всего сайта.
Компоненты — содержит стили для всех компонентов, создаваемых для веб-сайта, таких как кнопки, вкладки и модальные окна.
Макет — содержит файлы, необходимые для определения макета сайта, например верхние и нижние колонтитулы.
Страницы — содержит стили для каждой конкретной страницы.
Vendors — эта дополнительная папка подходит для платформы начальной загрузки, используемой проектом, например bootstrap
Создайте в каждой папке новый файл all.scss , содержащий все назначения для этой конкретной папки.
Многие сервисы предназначены для работы по всему миру. Затем, в некоторых случаях, компоненту требуется обслуживание. Традиционная практика компонентов кодирования рекомендует принцип единой ответственности.
При таком подходе сервисы и компоненты пишутся как отдельные проекты.
Но что произойдет, если вы решите удалить компоненты этих служб? В итоге вы получаете мертвый код, который только еще больше захламляет склад. В этом случае лучше всего поместить службу внутри компонента.
Таким образом, обслуживание компонентов и служб становится проще.
Во вложенной файловой структуре легче ориентироваться, чем в плоской файловой системе, в которой все файлы кода размещаются в одном каталоге.
Однако по мере приближения проекта файловая структура проекта может стать довольно сложной. Хотя это упрощает поиск кода, это создает проблемы при написании операторов импорта.
Когда структура каталогов начинает превышать три или четыре уровня, операторы import могут стать очень длинными и трудными для чтения.
Чтобы решить эту проблему, мы можем настроить псевдоним пути в файле tsconfig.json. В этом файле есть массив с именем compilerOptions . Это псевдоним пути, который вы настраиваете в своем приложении.
При компиляции кода псевдонимы путей, определенные в этом массиве, заменяются реальными путями. Значение каждого пути — это объект «ключ-значение», содержащий фактический путь и псевдоним.
Создание и расширение приложений Angular — это постоянная работа.