Релиз Angular 12
В мае вышла новая мажорная версия Angular. Марк Тексон рассказал о всех нововведениях релиза — «Angular v12 is now available».
— Экосистема Angular продолжает миграцию на пайплайн компиляции и рендеринга Ivy; View Engine с 12-ой версии задеприкейчен и будет удалён в одном из будущих релизов.
— Добавлены инструменты для автоматической миграции на новый формат идентификаторов сообщений i18n.
— Protractor (инструмент E2E-тестирования Angular-приложений) больше не используется при создании новых проектов. Его дальнейшая судьба пока неизвестна.
— Теперь @Component поддерживает инлайн SASS-кода. Добавлена поддержка новой модульной системы SASS. Angular CDK и Angular Material больше не поддерживают node-sass.
— Добавлена поддержка Nullish Coalescing в шаблонах. Завершена миграция на Webpack 5 и добавлена поддержка TypeScript 4.2. Команда ng update по умолчанию переключена в production-режим. Задеприкейчена поддержка IE11, она будет удалена полностью в следующей мажорной версии.
Angular получил новый синтаксис шаблонов
Новый синтаксис шаблонов, встроенное управление потоком данных и прощание с структурными директивами? В последние годы не так много менялось. Angular был стабильным для некоторых разработчиков и застойным для других. Теперь он движется вперед со сверхсветовой скоростью. Но куда именно он направляется?
Angular предлагает перейти от текущих структурных директив NgIf, NgForOf, NgSwitch к новому встроенному синтаксису.
Модернизация потока управления.
Команда Angular стремится заменить существующие структурные директивы NgIf, NgForOf, NgSwitch более современным синтаксисом, похожим на макросы. Хотя структурные директивы не исчезнут полностью, так как концепция останется прежней, этот новый способ написания шаблона будет предпочтительным. Он совместим со старым стилем шаблонов, и вы сможете использовать как старый, так и новый стиль в разных файлах в течение некоторого времени.
Эти изменения направлены на повышение читаемости и облегчение адаптации для широкой аудитории в мире фронтенд-разработки. Этот подход напоминает функциональный стиль и основан на синтаксисе шаблонов Svelte.
Привычный синтаксис.
trackByFunction в Angular — это пользовательская функция, которая используется для оптимизации производительности при итерации по большим коллекциям с помощью *ngFor. В текущем синтаксисе она принимает только функцию, а в новом формате будет работать только с свойствами.
Angular будет отслеживать изменения в коллекции на основе идентификатора каждого элемента, а не его идентичности. Это полезно, когда элементы в коллекции имеют уникальные идентификаторы и повышает эффективность при обновлении коллекции.
trackByFunction(index, item) < return item.id; > Item #>: > Новый синтаксис.
Item #>: > Новый синтаксис сохраняет несколько неявных переменных для представлений строк, таких как $index , $first , $last , $even и $odd в цикле for. Они доступны для использования напрямую, но также могут быть переименованы с помощью сегмента ‘ let ‘. Новый синтаксис также акцентирует использование ‘ track ‘ для циклов, чтобы улучшить производительность и оптимизировать различия в списках путем обеспечения отслеживания.
> There were no items in the list. Одна из важных новых функций — это empty блок, позволяющий разработчикам отображать шаблон, когда список не содержит элементов. Кроме того, Angular изменяет способ обработки различий в списках. Вместо использования настраиваемого IterableDiffers, Angular предоставит новый оптимизированный алгоритм для повышения производительности.
Блоки условий If-Else.
Если вы считаете, что оригинальный способ работы с ng-container и ng-template вместе с структурной директивой *ngIf недостаточно интуитивен, то новый поток управления может иметь ответ на ваши проблемы.
Привычный синтаксис.
Main case was true! Extra case was true! False case! Новый синтаксис.
Main case was true! Extra case was true! False case! Блок Switch.
Блок switch заменяет *ngSwitch. Говорят, что новый способ написания приносит значительные преимущества, такие как улучшенная проверка типов шаблона и отсутствие необходимости в контейнерных элементах для хранения условных выражений. Вот краткий обзор того, как это может выглядеть:
Case A. Case B. Default case. Что насчет миграции?
Переход на новый синтаксис обещает быть относительно гладким. Команда Angular работает над автоматической схемой миграции, которая позволит преобразовать старый синтаксис в новый. Однако разработчикам может потребоваться быть осторожными в отношении любого пользовательского алгоритма сравнения, используемого в их приложениях, поскольку это может повлиять на поведение новой директивы ‘for‘.
Будущие возможности.
Команда Angular видит возможность расширения этого нового синтаксиса для поддержки более разнообразных циклов JS, включая асинхронную итерацию и циклы for-in . Потенциальные улучшения в будущем также включают виртуальную прокрутку и поддержку деструктуризации.
Часто задаваемые вопросы.
Давайте быстро разберем некоторые распространенные вопросы, которые могут возникнуть у разработчиков относительно этого нового синтаксиса потока управления:
- Существующие структурные директивы: Текущие структурные директивы (NgIf и т.д.) будут продолжать работать. Однако Angular настоятельно рекомендует разработчикам перейти на новый синтаксис.
- Концепция структурной директивы: Она не будет удалена и остается важной функцией в Angular.
- Подсветка синтаксиса: Да, Angular Language Service будет выделять ключевые слова и выражения внутри блоков нового потока управления.
- Влияние на результаты запросов: Новый поток управления не повлияет на результаты запросов.
- Необходимость импорта нового потока управления: Нет, он будет интегрирован в язык шаблонов и автоматически доступен всем компонентам.
- Производительность: Новый поток управления может предложить незначительное улучшение, особенно для цикла ‘for’ и операции сравнения.
- Пользовательские группы блоков и директивы: В настоящее время новый синтаксис не поддерживает библиотеки для определения пользовательских групп блоков, и вы не можете добавлять директивы в блоки нового потока управления.
Что вы об этом думаете?
Предлагаемое изменение синтаксиса повлияет на способ написания ваших шаблонов. Вы считаете это необходимым? Это изменение улучшит ваш опыт разработки и привлечет новых разработчиков, которые ранее предпочитали использовать другие фреймворки?
Мои основные опасения касаются переходного периода. У нас уже есть значительное изменение в реактивных примитивах с помощью сигналов, а теперь вводится новый синтаксис шаблонов. Все это постепенно складывается в одну большую картину, которая пока нам не раскрыта. Некоторое время у разработчиков Angular будет много вариантов для работы с реактивностью: RxJS, сигналы, промисы, обнаружение изменений (zone.js) + 2 способа написания шаблонов.
Полный переход к новому видению определенно займет много времени, и нельзя ускорить этот процесс. Теперь вопрос заключается в том, стоят ли эти прогрессивные изменения того, что мы получим в конце концов?
Angular 12 что нового
13 мая компания Google анонсировала новую версию фреймворка Angular — Angular 12, Напомню, что новые версии фреймворка выходят два раза в год.
Основные изменения и обновления в Angular 12:
- Ранее использовавшийся движок представления View Engine объявлен устаревшим и будет удален в будущих релизах. Отныне единственным движком, который будет использоваться, стал движок Ivy . Стоит отметить, что библиотеки, которые сейчас применяют View Engine, также будут работать с приложениями, которые применяют движок Ivy. Однако авторам подобных библиотек рекомендуется переходить на Ivy.
- Изменения в системе локализации i18n — осуществлен переход к новому формату идентификаторов сообщений.
- В шаблоны Angular добавлена поддержка оператора ?? (nullish coalescing operator). Так, если раньше наличие значение проверялось с помощью следующего кода:
То при помощи оператора ?? код можно сократить следующим образом:
"inlineStyleLanguage": "scss”
Angular v12 is now available
It’s that time again, friends — we’re back with a new release and we can’t wait to share all the great updates and features waiting for you in Angular v12.
Before we dive into those updates, let’s check in on the Angular journey. A vital key to Angular’s future is Ivy and what it unlocks for the platform. We have been working over recent releases towards the goal of converging the Angular ecosystem on Ivy. We like to call this approach “Ivy Everywhere”.
Here are the changes we are making to enable this transition.
Moving Closer to Ivy Everywhere
The key moment in the next evolution of Angular has finally arrived — we are finally deprecating View Engine. This is what it means for the community.
- Now that View Engine is deprecated, it will be removed in a future major release.
- Current libraries using View Engine will still work with Ivy apps (no work is required by developers), but library authors should start planning to transition to Ivy.
We wrote a blog post providing details about this change and what it means for library authors and more.
Transitioning from Legacy i18n Message IDs
Currently, there are multiple legacy message id formats being used in our i18n system. These legacy message ids are fragile as problems can arise based on whitespace and the formatting templates and ICU expressions. To solve this problem we’re migrating away from them. The new canonical message id format is much more resilient and intuitive. This format will reduce the unnecessary translation invalidation and associated retranslation cost in applications where translations do not match due to whitespace changes for example.
Since v11, new projects are automatically configured to use the new message ids and we now have tooling to migrate existing projects with existing translations. Find out more here.
The Future of Protractor
The Angular team has been working with the community to determine the future of Protractor. We’re currently reviewing the feedback shared in the RFC. We’re still figuring out the best future for Protractor. We’ve opted to not include it in new projects and, instead, provide options with popular 3rd party solutions in the Angular CLI. We are currently working with Cypress, WebdriverIO, and TestCafe to help users adopt the alternative solutions. More information to come as this develops.
Nullish Coalescing
The nullish coalescing operator ( ?? ) has been helping developers write cleaner code in TypeScript classes for a while now. We’re thrilled to announce that you can bring the power of nullish coalescing to Angular templates in v12!
Now, in templates, developers can use the new syntax to simplify complex conditionals. For example:
Give this a try today and let us know what you think!
Learning Angular
We’re always working to improve the Angular learning experience for developers. As part of this effort, we have made some meaningful changes to our documentation. We wrote a content projection guide, with more new content in the works.
But there’s more to this story. We’ve gotten lots of feedback and questions asking how you can help us improve documentation. Great news, we’ve updated angular.io with a contributor’s guide that will help people looking to improve the docs. Check it out and help us make the docs better.
One more thing here — since our last major release, we’ve included guides and videos for error messages. The community has found this to be incredibly helpful so if you haven’t seen them, definitely check them out!
Stylish Improvements
Starting in v12, Angular components will now support inline Sass in the styles field of the @Component decorator. Previously, Sass was only available in external resources due to the Angular compiler. To enable this feature in your existing applications add «inlineStyleLanguage»: «scss” to angular.json . Otherwise, it will be available to new projects using SCSS.
In the v11.2 release, we added support for Tailwind CSS. To get started using it in projects: install the tailwindcss package from npm and then initialize Tailwind to create the tailwind.config.js in your project. Now, teams are ready to start using Tailwind in Angular.
Angular CDK and Angular Material have internally adopted Sass’s new module system. If your application uses Angular CDK or Angular Material, you’ll need to make sure you’ve switched from node-sass to the sass npm package. The node-sass package is unmaintained and no longer keeps up with new feature additions to the Sass language.
Additionally, both Angular CDK and Angular Material expose a new Sass API surface designed for consumption with the new @use syntax. This new API surface provides the same features, but with more meaningful names and more ergonomic entry points. All of the guides on material.angular.io have been fully rewritten to showcase this new API surface, as well as provide more detailed explanations of theming concepts and APIs.
When updating to v12 your app will automatically switch to the new Sass API by updating your application with ng update . This command will refactor any Sass @import statements for Angular CDK and Angular Material code over to the new @use API. Here’s an example of the before and after.
More Great Features
Let’s take a look at some of the other great updates that have made it into this release:
- Running ng build now defaults to production for new v12 projects which saves teams some extra steps and helps to prevent accidental development builds in production! It is important to note that this is only for new projects. The Angular tooling does not perform any automatic migrations. If you would like to try using the optional migration tools you can via:
ng update @angular/cli — migrate-only production-by-default
- Strict mode is enabled by default in the CLI. Strict mode helps catch errors earlier in the development cycle. Learn more about strict mode in the documentation and find the original announcement on our blog.
- The Ivy-based Language Service is moving from opt-in to on by default. The Language Service helps to boost your productivity when building apps by providing great features such as code completions, errors, hints, and navigation inside Angular templates. Check
out this video tour to learn more. - In the v11 update we added experimental support for Webpack 5. Today, we’re happy to announce that we’re releasing a productionready version of Webpack 5 support in Angular.
- We’re also updating the supported TypeScript version to 4.2 — check out this post for more details on what is included.
Deprecating Support for IE11
Angular is an evergreen platform, meaning that it stays up-to-date with the evolving web ecosystem. Removing support for legacy browsers allows us to focus our efforts on providing modern solutions and better support to developers and users.
We are going to start including a new deprecation warning message in Angular v12 — and remove support for IE11 in Angular v13.
You can view our decision rationale by going to this RFC.
Support From the Community
The Angular community has been hard at work improving the Angular experience for everyone by contributing to the framework — thank you! Here are some of the PRs that have been landed thanks to your incredible work:
- Avoid ngZone from throwing a navigation-related warning unnecessarily (#25839)
- HttpClient supports specifying request metadata (#25751)
- min and max Forms validators added (#39063)
- Support APP_INITIALIZER work with observables (#33222)
Conclusion
The Angular team has been hard at work serving the community in many areas. Be sure to follow us on Twitter for updates and on our revamped YouTube channel for fresh new content.
Which feature are you most excited about for v12? Comment on this post and let us know.
Thank you so much for being a part of the incredible Angular community. Until the next time, go build great apps!