Планирование архитектуры вашего приложения Angular

Эй, ребята. Я здесь, чтобы показать вам, как спланировать архитектуру вашего проекта Angular. Обратите внимание, что это не практическая статья, и, кроме того, цель этой статьи не в том, чтобы научить Angular, TypeScript или Angular CLI, а, скорее, предложить вам способ подумать об архитектуре вашего заявление. Итак, начнем. 😊

Цель

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

Архитектура

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

Планирование

Рисунок, который мы хотим построить дом. А теперь подумайте о проекте и ценности, которую он может иметь, особенно в наши дни с большими небоскребами, которые могут быть построены, например, в Дубае. Представьте, что вы не планируете подходящий размер фундамента, просто одна его часть может вызвать хаос. Я знаю, что создание приложения Angular - это не одно и то же, но я думаю, что применяются те же самые принципы, точно так же, как чертеж, и у архитектора была бы вся информация для построения успешного здания, нам также нужна конкретная вещь для планирования здания. нашего приложения. По-моему, все команды или каждый разработчик должны подумать об этом:

Обзор приложения = › Для чего это приложение? Какие цели? Как клиент собирается его использовать?
Функции приложения = › Конечно, это зависит от того, используете ли вы водопад или гибкий подход, но вы должны знать некоторые функции.
Безопасность домена = › Что такое безопасность домена? Вы используете правила на стороне сервера? Как они будут переданы вашему приложению Angular? Как ваше приложение будет взаимодействовать с вашими API?
Правила домена = › Какие у вас правила? Эти правила собираются запускать на стороне клиента или снова на сервере? Или оба? Обычно мы делаем это с обеих сторон, но вы должны спланировать такие вещи.
Services / Communication = › Как приложение будет взаимодействовать с сервером? В большинстве случаев вы будете использовать концепции HTTP. Однако в некоторых случаях может потребоваться использование WebSockets. Что ж, это хорошо знать заранее, потому что это изменит некоторые аспекты архитектуры обмена данными не только между серверной частью и клиентской частью, но даже между службами и компонентами в вашем приложении Angular.
Модели данных = › Какие данные из API? Что мы передаем компонентам? Получаем ли мы от API то, что хотим? Иногда нет. Итак, нам нужно подумать, как наиболее эффективно передавать данные по всему приложению.
Компоненты функций = › Каковы наши функции и как мы структурируем наши компоненты? Представьте, что две функции могут быть активны в приложении одновременно и им нужно взаимодействовать, как они собираются делать это слабосвязанным способом?
Общая функциональность = › Какие общие функции у нас есть? Используем ли мы сторонние компоненты, такие как Angular Material или Ng Bootstrap? Совместно ли общие функции можно использовать только в одном приложении или их можно использовать повторно?
Модульное тестирование = › Используем ли мы встроенные инструменты интерфейса командной строки? Мы можем использовать средство выполнения тестов Karma и тому подобное.
Сквозное тестирование = › Что мы для этого делаем? Используем транспортир или новейший Cypress? Я предпочитаю Cypress 😊. Это может фактически повлиять на то, как вы разрабатываете свой код, потому что ваши тестировщики (если у вас есть для этого команда) могут предпочесть иметь идентификаторы на некоторых из ваших тегов, чтобы их было легче найти. для теста.

Есть еще баллы? Безусловно, каждое приложение отличается, каждая компания индивидуальна. Но в том-то и дело, придумайте что-то, что хорошо работает для вашей команды, вашей компании и для вас.

Как организовать функции

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

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

На основе конвенций и на основе функций
→ Когда я был внутренним разработчиком (.net C #), я, например, следовал принципу соглашения с шаблоном MVC. Теперь, когда я больше занимаюсь разработкой Angular и думаю о том, как мне нужно (и нравится) организовать свой код и функции, я предпочитаю не использовать, а это означает, что я не хочу организовывать свои папки следующим образом:
Папка с именем components, куда я просто сбрасываю туда все свои компоненты, и папка с именем services для всех моих файлов служб. Это наверняка сработает, но с компонентами, теперь наше представление или шаблон будут полностью отдельными, мой CSS будет отдельным, и, таким образом, мне нужно будет немного покопаться. Итак, подход, который я рекомендую, основан на функциях, и это то, что CLI будет делать по умолчанию, как вы можете видеть в этой статье. Все функции организованы в отдельные папки, все они автономны, и все, что для данной функции довольно легко найти.

Возможности Модули

Предположим, у нас есть клиентский модуль, а также есть функция заказов. Как мы нормально стартуем? Что ж, сначала мы сделаем ng gc (прочтите эту статью, чтобы лучше узнать некоторые команды интерфейса командной строки), и назвали бы его клиенты, и это добавьте подпапку клиенты на верхнем уровне. На этом этапе многие люди останавливаются и в конечном итоге добавляют эту функцию в корневой модуль. Это совершенно нормально, но по мере того, как приложение будет расти и вы получите больше функций, у вас будет только один модуль, поэтому вы не сможете использовать отложенную загрузку, и эта функция больше не будет автономной. Я рекомендую вам использовать один модуль для каждой функции, и преимущества этого заключаются не только в ленивой загрузке. Например, с помощью автономных функций у нас могут быть разные члены команды, работающие над данной функцией и в значительной степени владеющие этой функцией, и если вам, как и мне, нравится соблюдать принцип единой ответственности, это тоже хорошо.

Основные и общие модули

Основной модуль рекомендован Руководством по стилю Angular. Ядро действительно предназначено для вашего типа одноэлементных служб, всего, что будет совместно использоваться во всем приложении, и, очевидно, любой синглтон подойдет для этого.
→ Службы, относящиеся к функции, могут находиться в папке функции. В этом сценарии я бы создал подпапку, назвал ее службами, поместил ее в папку функций, а затем эта конкретная служба была бы просто импортирована или предоставлена непосредственно в функциональный модуль. Это имеет смысл только в том случае, если эта услуга не будет повторно использоваться где-либо еще.
В общем модуле находятся наши повторно используемые компоненты, каналы, директивы и т. Д. Важным отличительным фактором этого является то, будут ли компонент, канал или директива использоваться только в этом приложении или могут использоваться во всех приложениях? Он настолько универсален, что вы можете использовать его снова и снова? В таком случае не публикуйте его. Вот тогда мы и хотим поговорить о создании библиотеки Angular, о которой я постараюсь рассказать в своих следующих статьях 😊.

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

Модули вместе

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

Функциональный модуль обычно является автономным и импортируется только в корень.
Модуль маршрутизации обычно мы импортируем нашу маршрутизацию, а затем экспортируем ее.
Базовый модуль будет импортирован только в наш корневой модуль, поэтому этот модуль обычно не экспортирует.
Общий модуль - это тот модуль, который почти всегда будет иметь некоторый экспорт, потому что в противном случае он наверняка не будет доступен для совместного использования.

Заключение

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

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