Что нужно знать для эффективной разработки на фреймворке Angular

Автор оригинала: Aphinya Dechalert
  • Перевод


Считается, что во фронтенд-разработке эквивалентом «Hello world» является приложение — список задач. Да, это позволяет охватить CRUD-аспект создания приложения, однако возможности используемых фреймворка или библиотеки при этом часто затрагиваются весьма поверхностно.

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

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

Переведено в Alconost

1. Модульная архитектура Angular


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

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

Упорядочить модули в приложении можно самыми разными способами. Изучая различные архитектурные структуры, можно определиться с тем, как приложение будет масштабироваться по мере развития, а также научиться изолировать код и снижать взаимозависимость.

Что гуглить:

  • архитектурные шаблоны Angular,
  • масштабируемая архитектура приложений Angular.

2. Односторонний поток данных и неизменяемость


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

Оказалось, что двусторонняя привязка нужна не везде

Angular 2+ все еще дает возможность ее осуществить, но для этого ее необходимо явно затребовать — поэтому разработчику приходится думать о потоках данных и их направлении. Кроме того, это позволяет приложению более гибко обращаться с данными, поскольку можно указать, как следует их передавать.

Что гуглить:

  • работа с потоками данных в Angular,
  • однонаправленный поток в Angular,
  • преимущества односторонней привязки.

3. Атрибутивные и структурные директивы


Директива — это расширение HTML с помощью дополнительных элементов. Атрибутивные директивы позволяют изменять свойства элемента. Структурные директивы изменяют макет, добавляя или удаляя элементы DOM.

Например, ngSwitch и ngIf — структурные директивы: они оценивают параметры и определяют, должны ли существовать конкретные части DOM.

Атрибутивные директивы представляют собой настраиваемое поведение, прикрепленное к элементу, компоненту или другим директивам.

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

Что гуглить:

  • атрибутивные директивы Angular,
  • структурные директивы Angular,
  • шаблоны структурных директив Angular.

4. Обработчики жизненного цикла компонента


У каждого приложения есть жизненный цикл, который определяет, как объекты создаются, обрабатываются, а затем удаляются. Во фреймворке Angular жизненный цикл компонента выглядит примерно так:

создание → отрисовка → отрисовка дочерних элементов → проверка изменения свойств при связывании данных → уничтожение → удаление из DOM

У нас есть возможность обрабатывать ключевые моменты этого цикла и нацеливаться на определенные моменты времени или события. Это позволяет создавать соответствующие отклики и настраивать поведение в соответствии с различными этапами существования компонента.

Например, если требуется загрузить некоторые данные до отрисовки страницы, это можно сделать через ngOnInit(). А если нужно отключиться от базы данных, это можно сделать в момент ngOnDestroy().

Что гуглить:

  • обработчики жизненного цикла компонента в Angular;
  • жизненный цикл компонента.

5. Наблюдаемые сервисы и HTTP


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

Что гуглить:

  • шаблоны наблюдателя в JavaScript,
  • наблюдаемые объекты и HTTP в Angular,
  • наблюдаемые объекты в ES7.

6. Архитектура «умных» и «глупых» компонентов


Часто при написании приложений на Angular всё сваливают в один компонент, однако это не самый лучший подход. Концепция «умных» и «глупых» компонентов в Angular определенно заслуживает большего внимания, особенно в среде новичков.

Роль компонента в общем плане приложения определяется тем, «глупый» он или «умный». «Глупые» компоненты обычно не отслеживают состояние, а их поведение легко предсказать и понять — по возможности именно такими нужно делать компоненты.

«Умные» компоненты сложнее в понимании, поскольку в них задействованы входы и выходы. Для эффективного использования возможностей Angular следует разобраться с архитектурой «умных» и «глупых» компонентов: так вы овладеете шаблонами и образом мыслей, которые помогут писать более продуктивный код и выстроить правильное взаимодействие внутри приложения.

Что гуглить:

  • умные и глупые компоненты Angular,
  • глупые компоненты без состояния,
  • презентационные компоненты,
  • умные компоненты Angular.

7. Стандартные структуры приложений


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

И Angular здесь — не исключение.

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

Что гуглить:

  • приложения Angular с одним репозиторием,
  • библиотеки Angular, пакеты Angular,
  • бандлы Angular,
  • микроприложения Angular.
  • монорепозитории.

8. Синтаксис для привязки к шаблону


Изюминка рассматриваемого JavaScript-фреймворка — привязка, она же и стала одной из причин его создания. Привязка к шаблону объединяет статический HTML и JavaScript, и синтаксис Angular для привязки к шаблону действует как посредник между этими двумя технологиями.

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

Что гуглить:

  • привязка к свойствам в Angular,
  • привязка к событиям в Angular,
  • двусторонняя привязка в Angular, интерполяция в Angular,
  • передача констант в Angular.

9. Маршрутизация и функциональные модули


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

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

Что гуглить:

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

10. Формы и проверка данных (реактивные формы и валидаторы)


Формы — неотъемлемая часть фронтенд-разработки.

А где формы, там и проверка данных.

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

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

Что гуглить:

  • проверка форм в Angular,
  • проверка данных на основе шаблонов,
  • проверка реактивных форм,
  • синхронные и асинхронные валидаторы в Angular,
  • встроенные валидаторы,
  • пользовательские валидаторы в Angular,
  • перекрестная проверка полей.

11. Проецирование контента


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

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

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

Что гуглить:

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

12. Стратегия обнаружения изменений «onPush»


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

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

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

Что гуглить:

  • обнаружение изменений onPush в Angular.

13. Защитники маршрутов, предварительная и отложенная загрузка


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

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

Что гуглить:

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

14. Нестандартные каналы


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

И вот здесь пригодятся нестандартные каналы, которые позволяют с легкостью создавать собственные фильтры и преобразовывать форматы данных требуемым образом. Это довольно легко — попробуйте.

Что гуглить:

  • нестандартные каналы в Angular.

15. Декораторы @ViewChild и @ContentChild


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

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

Что гуглить:

  • декораторы Angular,
  • ViewChild и ContentChild в Angular,
  • обмен данными между компонентами в Angular.

16. Динамические компоненты и «ng-template»


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

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

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

Что гуглить:

  • динамические компоненты в Angular,
  • динамические компоненты и «ng-template».

17. Host, HostBinding и «exportAs»


@Host, @HostBinding — декораторы, а exportAs — свойство декоратора @Directive. Их назначение — расширять действие параметров, к которым они прикреплены. Также они дают возможность создавать небольшие шаблоны экспорта для использования внутри приложения.

Если вышеперечисленное звучит непонятно, следует изучить директивы Angular и понять их назначение. @Host, @HostBinding и exportAs — важные элементы концепции директив.

Что гуглить:

  • шаблоны использования директив в Angular,
  • @Host, @HostBinding и exportAs в Angular.

18. Управление состоянием с помощью NgRx


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

Разобравшись в том, для чего в Angular нужны состояния, вы поймете, как и почему данные ведут себя именно так, а не иначе.

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

Что гуглить:

  • Angular NgRx,
  • принципы Flux и Redux,
  • принципы управления состоянием в Angular.

19. Зоны и внедрение зависимостей


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

Как и внедрение зависимостей, «зоны» были и до Angular. Они позволяют приложению обнаруживать асинхронные задачи. Это важно, поскольку асинхронные задачи способны изменять внутренние состояния приложения — а следовательно, и представление. Зоны же упрощают обнаружение изменений.

Что гуглить:

  • зоны в Angular,
  • внедрение зависимостей,
  • Angular DI.

Заключение


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

О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией игр, приложений и сайтов на 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

→ Подробнее
Alconost
177,16
Локализуем на 70 языков, делаем видеоролики для IT
Поделиться публикацией

Комментарии 17

    +2
    14. Нестандартные каналы


    Под 'каналами' подразумеваются пайпы? (pipes)
    Ни разу не встречал термин 'канал'

    Управление состоянием с помощью NgRx

    Почему именно ngrx?
    Во-первых, это не является неотъемлёмой частью angular.
    Во-первых, ангуляр из коробки позволяет обойтись без сторонних менеджеров состояний с помощью rxjs и сервисов.
    Во-вторых, ngrx сложнее для понимания, чем, например, акита и ngxs

    У фреймворка Angular есть собственная система управления состояниями, но NgRx справляется с централизацией состояний и связанных с ними данных намного лучше

    Очень голословное утверждение

    Так же, почему нет ни слова про rxjs, который глубоко интегрирован в сам ангуляр (в отличие от например ngrx) и действительно является мощным инструментом, который следует изучить?
      +2
      У всех разный опыт работы с angular и эта статья основана на опыте ее написавшего. Возможно автор не копал глубоко и использовал только свой опыт и свое понимание работы с angular.
      Инструментов и подходов же много и нет единственно правильного подхода или инструмента для решения задач.
      ИМХО.
        0
        не копал глубоко и использовал только свой опыт и свое понимание работы с angular.

        Если не копал глубоко и использует только свой опыт, зачем писать под видом истины статью "Что нужно знать..."

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

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

              0
              jQuery же учили практически без знаний js. Что мешает тут поступать так же? :)
              Я говорю, что у каждого свой подход, в том числе и в изучении чего-либо. Кому то проще начать на сторонней либе и гуглить по ходу разработки, чем изучить сначала RxJS, потом делать что то с помощью нее, а уже потом юзать NgRx, если вдруг надо больше возможностей. Разработчик и так познакомится с RxJS при работе с NgRx. Это неизбежно, но он уже будет что то делать полезное для себя или для компании, которая доверила ему проект на Angular.
                0
                Query же учили практически без знаний js. Что мешает тут поступать так же? :)

                Это немного разные вещи, тут предлагают учить jquery с помощью jquery ui

      0
      Полезна статья, спасибо. А почему Angular 2, а не более свежие версии?
        0
        Angular 2+
          0
          Потому что все версии от 2 и выше принято называть «Angular 2».
            0
            Спасибо, понял, не знал
          0
          > Считается, что во фронтенд-разработке эквивалентом «Hello world» является приложение — список задач.

          Нет, простите, но это уже никак «Hello world» не считается.
            0
            А что считается?
            Напомню, что фронтенд-разработка — это совокупность верстки и программирования для клиентской части приложения.
            А что в себе объединяет верстку+программирование+делается за вечерок? Правильно, приложение todo-лист в самом его простом исполнении.
            Чтобы понять, как работает фреймворк, нужно же не вывести в консоль или темплейт «Hello, world», а сделать что то более осмысленное.
              +1
              Возможно, я неправильно воспринимаю «Hello world». Для меня это, например, завести React и заставить отрендерить компонент с таким текстом, то есть самый первый, начальный уровень.

              С to-do тоже согласен, что это удобно в контексте того, чтобы попробовать новую технологию сразу в практике, но это, как по мне, уже выше уровнем, нежели «Hello world».

              Само собой, это моё мнение, не претендую на абсолютную правоту.
                0
                Вывод «Hello world» в свежесгенерённом проекте же!

                TODO это уже приложение. Маленькое, но приложение.
              0

              Спасибо за перевод.


              В разделах "что гуглить" мне лично не хватает оригинальных названий терминов. Каналы — это channels? Глупые компоненты — silly? dumb? stupid? Нестандартные компоненты — non-standard? custom?


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

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

            Самое читаемое