Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
Выжмите из Angular — ведущего фреймворка для динамических приложений JavaScript — всё. Адам Фримен начинает с описания MVC и его преимуществ, затем показывает, как эффективно использовать Angular, охватывая все этапы: начиная с основ и до самых передовых возможностей, которые кроются в глубинах этого фреймворка. Каждая тема изложена четко и лаконично, снабжена большим количеством подробностей, которые позволят стать вам действительно эффективными. Наиболее важные фичи даны без излишних подробностей, но содержат всю необходимую информацию, чтобы вы смогли обойти все подводные камни.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 808
Veröffentlichungsjahr: 2022
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Переводчик Е. Матвеев
Технический редактор Н. Лукьянова
Художники Л. Егорова, С. Заматевская
Корректоры С. Беляева, Н. Викторова
Верстка Н. Лукьянова
А. Фримен
Angular для профессионалов. — СПб.: Питер, 2021.
ISBN 978-5-4461-0451-2
© ООО Издательство "Питер", 2021
Все права защищены. Никакая часть данной книги не может быть воспроизведена в какой бы то ни было форме без письменного разрешения владельцев авторских прав.
Посвящается моей милой жене Джеки Грифит. И Крохе, которая тоже бывает милой, когда постарается
Адам Фримен (Adam Freeman) — опытный профессионал в области IT, занимавший руководящие должности во многих компаниях. До недавнего времени он занимал посты технического директора и главного инженера в одном из крупнейших банков. Сейчас Адам посвящает свое время в основном написанию книг и бегу на длинные дистанции.
Фабио Клаудио Феррачиати (Fabio Claudio Ferracchiati) — старший консультант и ведущий аналитик/разработчик с опытом использования технологий Microsoft. Он работает на BluArancio (www.bluarancio.com). Фабио является сертифицированным разработчиком программных решений для .NET, сертифицированным разработчиком приложений для .NET, сертифицированным профессионалом Microsoft, плодовитым писателем и научным редактором. За последние 10 лет он написал ряд статей для итальянских и международных журналов и участвовал в написании более 10 книг по различным областям компьютерной тематики.
После выхода оригинального издания на английском языке, автор обновил книгу для Angular 4 and angular-cli. Эти изменения затронули ключевые главы и все листинги. Русскоязычным читателям повезло, мы внесли соответствующие изменения в книгу и теперь вы сможете использовать Angular 4 and angular-cli в своих проектах.
Файлы к книге можно скачать по ссылке www.apress.com/gp/book/9781484223062
Ваши замечания, предложения, вопросы отправляйте по адресу [email protected] (издательство «Питер», компьютерная редакция).
Мы будем рады узнать ваше мнение!
На веб-сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.
В этой главе я представлю Angular в контексте разработки веб-приложений и заложу основу для материала последующих глав. Основная цель Angular — открыть веб-клиенту доступ к инструментам и возможностям, которые ранее были доступны только в разработке на стороне сервера, и тем самым упростить разработку, тестирование и сопровождение сложных и полнофункциональных веб-приложений.
Angular позволяет вам расширять HTML… Идея может показаться странной, пока вы к ней не привыкнете. Приложения Angular выражают функциональность при помощи нестандартных элементов, а сложное приложение может построить документ HTML, в котором смешивается стандартная и нестандартная разметка.
Стиль разработки, поддерживаемый Angular, основан на использовании паттерна MVC (Model — View — Controller, «модель — представление — контроллер»), хотя его иногда называют «модель — представление — что угодно», потому что существуют бесчисленные вариации этого паттерна, которые могут использоваться с Angular. В книге я сосредоточусь на стандартном паттерне MVC, потому что он был наиболее глубоко проработан и широко применяется на практике. Ниже я опишу характеристики проектов, в которых применение Angular может принести значительную пользу (и тех, для которых существуют более удачные альтернативы), опишу паттерн MVC и некоторые распространенные проблемы при его использовании.
Книга и график выпусков Angular
Компания Google приняла агрессивный план выпуска Angular, начиная с Angular 2.0. Это означает, что дополнительные версии будут появляться постоянно, а основная версия будет выходить каждые полгода. Дополнительные версии не должны нарушать существующую функциональность; в основном они содержат исправления ошибок. Основные версии вводят значительные изменения с возможной потерей обратной совместимости. Согласно этому графику, за версией Angular 2.0, выпущенной в сентябре 2016 года, версии Angular 4.0 и Angular 5.0 последуют в марте и сентябре 2017 года. (Версии 3.0 не будет, а за Angular 2.0 сразу последует Angular 4.0.)
Было бы нечестно и неразумно предлагать читателям покупать новое издание книги через каждые полгода, особенно с учетом того, что основные возможности Angular вряд ли изменятся даже с выходом основной версии. Вместо этого я буду публиковать обновления в репозитории GitHub этой книги (ссылка на него имеется на сайте apress.com).
Такой подход станет экспериментом для меня, и я не знаю, какую форму могут принять такие обновления, еще и потому, что не знаю, что изменится в основных версиях Angular. При этом мы хотим продлить срок жизни книги дополнением содержащихся в ней примеров.
Я не даю никаких обещаний относительно того, как будут выглядеть такие обновления, какую форму они примут и сколько времени я буду работать над ними перед включением в новое издание книги. Пожалуйста, относитесь непредвзято и проверяйте содержимое репозитория книги при выходе новых версий Angular. Если в ходе эксперимента у вас появятся мысли относительно того, как можно улучшить эти обновления, поделитесь ими со мной по адресу [email protected].
Angular не панацея. Важно знать, когда следует применять Angular, а когда лучше поискать альтернативу.
Angular предоставляет функциональность, которая когда-то была доступна исключительно разработчикам на стороне сервера, но теперь требует только наличия браузера. Это означает, что Angular приходится проделывать значительную работу при каждой загрузке документа HTML, к которому применяется Angular: необходимо откомпилировать элементы HTML, обработать привязки данных, выполнить другие структурные элементы и т.д. Все это обеспечивает поддержку тех возможностей, которые были описаны в главе 2 и еще будут описаны в последующих главах книги.
Выполнение такой работы требует времени. Это время зависит от сложности документа HTML, сопутствующего кода JavaScript и — самое важное — от качества браузера и вычислительной мощи устройства. В новейшем браузере на высокопроизводительной настольной машине вы не заметите никаких задержек, но в старом браузере на слабом смартфоне инициализация приложений Angular основательно замедляется.
Таким образом, разработчик должен стараться выполнять инициализацию как можно реже, а если уж она выполняется — предоставить пользователю как можно больше функциональности. Это означает, что вы должны тщательно продумать, какое веб-приложение собираетесь построить. В широком смысле веб-приложения делятся на две категории: приложения с круговой передачей (round trip) и одностраничные приложения (single-page).
В течение долгого времени веб-приложения строились по модели круговой передачи. Браузер запрашивает у сервера исходный документ HTML. Взаимодействия с пользователем — щелчок на ссылке, отправка данных формы — приводят к тому, что браузер запрашивает и получает совершенно новый документ HTML. В таких приложениях браузер фактически становится средством визуализации контента HTML, а вся логика и данные приложения размещаются на сервере. Браузер выдает серию запросов HTTP, не имеющих состояния; сервер обрабатывает эти запросы и динамически генерирует документы HTML.
Большая часть современной разработки веб-приложений по-прежнему ориентирована на приложения с круговой передачей. В основном это объясняется тем, что такие приложения почти ничего не требуют от браузера, что гарантирует максимально широкую поддержку клиентов. Однако у приложений с круговой передачей есть серьезные недостатки: они заставляют пользователя ждать, пока будет запрошен и загружен следующий документ HTML; они требуют масштабной инфраструктуры на стороне сервера для обработки всех запросов и управления всем состоянием приложения; они создают повышенную нагрузку на канал, потому что каждый документ должен быть автономным (в результате чего один и тот же контент должен включаться в каждый ответ от сервера).
Одностраничные приложения идут по другому пути. Исходный документ HTML отправляется браузеру, но взаимодействия с пользователем порождают запросы Ajax для получения небольших фрагментов HTML или вставки данных в существующие наборы элементов с последующим выводом. Исходный документ HTML никогда не перезагружается и не замещается; пользователь продолжает взаимодействовать с существующим документом HTML, пока запросы Ajax выполняются асинхронно, даже если взаимодействие сводится к просмотру сообщения «Загрузка данных…».
Многие современные приложения занимают промежуточное место между этими двумя крайностями. Базовая модель круговой передачи, дополненная JavaScript, сокращает количество полных изменений страницы, хотя основное внимание часто уделяется сокращению количества ошибок на формах за счет выполнения проверки на стороне клиента.
Angular обеспечивает наибольшую отдачу от повышения исходных затрат ресурсов тогда, когда приложение приближается к одностраничной модели. Это не означает, что Angular нельзя использовать с приложениями с круговой передачей, — можно, конечно, но существуют и другие технологии, более простые и лучше подходящие для раздельных страниц HTML, основанные либо на выполнении прямых операций с DOM API, либо на использовании библиотек, упрощающих работу с ним (таких, как jQuery). На рис. 3.1 изображена диаграмма типов веб-приложений и область наиболее эффективного применения Angular.
Angular хорошо работает в одностраничных приложениях, и особенно в сложных приложениях с круговой передачей. В более простых проектах лучше использовать прямые операции с DOM API или такие библиотеки, как jQuery, хотя ничто не мешает вам применять Angular во всех ваших проектах.
В современных проектах веб-приложений существует тенденция постепенного перехода на модель одностраничных приложений. Она создает идеальные условия для применения Angular, и не только из-за процесса инициализации, а еще и потому, что преимущества паттерна MVC (о котором я расскажу позднее в этой главе) в полной мере проявляются в более крупных и сложных проектах, которые способствуют переходу на одностраничную модель.
Рис. 3.1. Angular хорошо подходит для модели одностраничных приложений
Примечание
Angular и другие похожие фреймворки появились из-за того, что сложные веб-приложения создавали много трудностей в программировании и сопровождении. Проблемы, с которыми сталкивались такие проекты, привели к разработке инструментов промышленного масштаба, таких как Angular. Благодаря этим инструментам появилась возможность создания следующего поколения сложных проектов. Такой вот механизм развития с обратной связью.
Angular и jQuery
Angular и jQuery используют разные подходы к разработке веб-приложений. Сутью jQuery являются явные манипуляции с браузерной моделью DOM. Angular же привлекает браузер к участию в разработке приложения.
Безусловно, jQuery — эффективный инструмент, которым я люблю пользоваться. Библиотека jQuery мощна и надежна, она позволяет практически сразу же получить результаты. Мне в ней особенно нравится динамичный API и простота расширения базовой библиотеки jQuery. Если вы захотите больше узнать о jQuery, обратитесь к моей книге «Pro jQuery», опубликованной Apress; в ней подробно рассматриваются jQuery, jQuery UI и jQuery Mobile.
Но при всей моей любви к jQuery эта библиотека ничуть не более универсальна, чем Angular. Разработка и сопровождение больших приложений на базе jQuery создают изрядные трудности, как и организация тщательного модульного тестирования.
Angular также использует DOM для представления контента HTML пользователю, но совершенно иначе подходит к построению приложений: основное внимание уделяется данным в приложении и связыванию их с элементами HTML через динамические привязки данных.
Главный недостаток Angular заключается в том, что эта технология требует значительных начальных затрат времени разработки перед тем, как вы увидите первые результаты, — это явление вообще типично для любой разработки на базе MVC. Тем не менее эти исходные затраты оправданны для сложных приложений или приложений, требующих значительных усилий по переработке и сопровождению.
Короче говоря, используйте jQuery (или прямые операции с DOM API) для веб-приложений незначительной сложности, для которых модульное тестирование некритично, и когда вы хотите немедленно получить результаты. Используйте Angular для одностраничных веб-приложений, когда у вас есть время для тщательного планирования и проектирования и когда вы можете легко управлять разметкой HTML, сгенерированной сервером.
Термин MVC появился в конце 1970-х годов в ходе работы над одним проектом Smalltalk в Xerox PARC, где эта концепция была предложена для определения структуры первых приложений с графическим интерфейсом. Некоторые аспекты исходного паттерна MVC были связаны с понятиями, специфическими для Smalltalk (такими, как экраны и инструменты), но более широкие идеи применимы к любым приложениям и особенно хорошо подходят для веб-приложений.
Паттерн MVC впервые закрепился на серверной стороне веб-разработки через такие инструментарии, как Ruby on Rails и ASP.NET MVC Framework. За последние годы паттерн MVC также рассматривался как средство управления растущей сложностью и широтой функциональности веб-разработки на стороне клиента. Именно в этой среде появилась технология Angular.
В применении паттерна MVC основную роль играет реализация ключевого принципа разделения обязанностей, согласно которому модель данных в приложении отделяется от бизнес-логики и логики представления. В разработке на стороне клиента это означает разделение данных, логики, работающей с этими данными, и элементов HTML, используемых для отображения данных. В результате вы получаете клиентское приложение, более простое в разработке, сопровождении и тестировании.
Три основных структурных блока — модель, контроллер и представление. На рис. 3.2 представлена традиционная структура паттерна MVC применительно к разработке на стороне сервера.
Рис. 3.2. Реализация паттерна MVC на стороне сервера
Я позаимствовал эту диаграмму из своей книги «Pro ASP.NET Core MVC», в которой описана реализация паттерна MVC на стороне сервера от компании Microsoft. Как видно из диаграммы, предполагается, что модель берется из базы данных, а целью приложения является обслуживание запросов HTTP от браузера. Эта схема лежит в основе веб-приложений с круговой передачей, упоминавшихся ранее.
Конечно, Angular существует в браузере, и этот факт оказывает влияние на MVC, как показано на рис. 3.3.
Рис. 3.3. Реализация паттерна MVC на стороне клиента
Реализация паттерна MVC на стороне клиента получает свои данные от компонентов на стороне сервера, обычно через REST-совместимую веб-службу (см. главу 24). Целью контроллера и представления является работа с данными модели и выполнение манипуляций с DOM для создания элементов HTML, с которыми может взаимодействовать пользователь, и управления ими. Взаимодействия передаются обратно контроллеру; таким образом замыкается цикл работы интерактивного приложения.
В Angular используется несколько иная терминология для обозначения структурных блоков. Модель MVC, реализованная средствами Angular, ближе к рис. 3.4.
Рис. 3.4. Реализация паттерна MVC в Angular
Диаграмма демонстрирует соответствие между структурными элементами Angular и элементами паттерна MVC. Для поддержки паттерна MVC Angular предоставляет широкий набор дополнительных возможностей, которые будут описаны в книге.
Примечание
Использование клиентского фреймворка, такого как Angular, не исключает применения серверного фреймворка MVC, но как вы вскоре увидите, клиент Angular способен взять на себя часть сложности, которая бы в противном случае размещалась на сервере. Обычно это хорошо, потому что нагрузка перемещается с сервера на клиента, что позволяет обслуживать большее количество клиентов при снижении затрат ресурсов сервера.
Паттерны и фанатизм
Хороший паттерн описывает подход к решению задачи, который хорошо сработал для других людей в других проектах. Паттерны — рецепты, а не правила, и вы должны адаптировать любой паттерн для ваших конкретных проектов подобно тому, как повар адаптирует рецепт для разных печей и доступных ингредиентов.
Степень возможного отклонения от паттерна определяется необходимостью и опытом. Время, которое вы потратили на применение паттерна в похожих проектах, позволит вам понять, что подходит или не подходит для вашей конкретной ситуации. Если вы недавно работаете с паттерном или беретесь за проект нового типа, лучше придерживайтесь паттерна как можно точнее, пока вы не начнете понимать все преимущества и проблемы, которые вас поджидают. Однако не старайтесь переделывать всю разработку «под паттерн», потому что широкомасштабные изменения обычно приводят к потере производительности, а это противоречит тому, чего вы рассчитывали добиться при помощи паттерна.
Паттерны — гибкие инструменты, а не жесткие правила, но не все разработчики понимают это. Некоторые из них относятся к паттернам с излишним фанатизмом; такие люди проводят больше времени за разговорами о паттернах, чем за применением их в проектах, а любое отклонение от их интерпретации паттерна считается серьезным преступлением. Просто не обращайте внимания на таких людей, потому что любые споры только обернутся напрасной тратой усилий, а переубедить их вам все равно не удастся. Вместо этого просто выполните свою работу и покажите, как гибкое применение паттерна позволяет добиться хороших результатов на практике.
Учитывая все сказанное, вы увидите, что в примерах книги я следую общим концепциям паттерна MVC, но при этом адаптирую паттерн для демонстрации различных возможностей и приемов. Именно так я поступаю в своих проектах — задействую те части паттернов, которые приносят пользу в конкретной ситуации, и откладываю в сторону все лишнее.