Если HTML5 может любой произвольный тег считать чем-то валидным, то Angular, например, будет пытается распарсить это тег как компонент, не сможет его найти и сломается на этапе билда.
Соглашусь, можно написать нативно. Тогда будет банд маленького размера, ну или как минимум меньше, чем нам достанется от Angular.
Но стоит смотреть на ситуацию под разными углами. Например, форма может уже существовать в рамках другого Angular-приложения. Тогда создать вторую форму на нативных технологиях будет "дороже", как по написанию, так и по поддержке, придётся повторять одну и ту же логику дважды на разных технологиях.
Имея под рукой UI-кит, инструменты для работы с формами и т.д., можно ускориться в процессе разработки, что тоже важно. А также готовые и проверенные инструменты уберегут нас от мелких проблем, таких как, например, баги кроссбраузерной верстки.
Также стоит смотреть в сторону дальнейшего развития функционала. Сегодня у нас два поля и кнопка, а завтра это может быть форма со степпером или другой логикой. Придётся создавать "конструктор форм", что уже будет на порядок сложнее.
Не часто выпадают такие задачи, поэтому, в целом, не было понимания на каком уровне находятся web components. Очень классный и мощный инструмент, но все же имеет свои плюсы и минусы. Так что все равно приходится подбирать инструмент под задачи. Тот же Youtube встраивает свои видео через iframe.
Чтобы использовать *ngIf нужно импортировать commonModule, или импортировать из него NgIf-директиву. Это не очень удобно, особенно в разрезе standalone-компонентов. А @if не требует импорта, это часть синтаксиса шаблона, что убирает ещё один импорт. Про то, что не нужен в некоторых кейсах ng-component, я уже написал.
Также, новый синтаксис для for обязывает имеет trackBy, но тут же упрощает его использование, достаточно при описании написать что-то типа `@for(item of items; track item.id)`, и получаем уменьшение перерисовок с привязкой к id-сущности.
С 17 версии Angular появился новый синтаксис в шаблонах@for , @if , @switch, которые позволяют избежать использования ng-container в описанных выше кейсах. Например, так:
@if(expression){
<div>first part content </div>
<div>second part content </div>
}
В кейсах с ngTemplateOutlet он вполне подходит, а вот вместе с новыми фичами шаблона - стал в большинстве случаев лишним.
Понятно, что там где нет code-review все будет очень плохо, сам работал без него однажды
Использовать дефолтные настройки не очень правильно, потому что у разработчиков могут быть разные IDE с разными дефолтными настройками. Разумно иметь единый источник правил, чтобы у всех разрабов был единый формат кода (был случай, когда поменял одну строку, но переформатировался весь файл).
"Спецификация дизайн", опечатался немного (спецификация или дизайн-ревью), но подразумевал спецификацию решения, или дизайн ревью решения. Какая-то активность, результатом которой будет описание технического решения, которое устроит остальных разработчиков, системных аналитиков или архитекторов (смотря какая команда)
Кажется разумным автоматизировать все, что можно автоматизировать: линтеры/форматтеры кода и прочие плюшки, которые делают код красивым. Чтобы не тратить на это время при ревью.
Иметь набор договоренностей и стайлгайды, которым следует команда. Но они могут пересматриваться
Делать какую-то спецификацию дизайн разумно, если делается что-то новое. Можно выделить отдельным этапом во флоу разработки, и еще на этапе анализа понять как делать.
Именно бизнес-полопёку лучше получать из интеграционных тестов, или е2е-тестов, так как они отображают юзер-кейсы. А вот суть того, как работает конкретный метод/функция можно узнать из юнит-теста. Конечно, в первую очередь стоит смотреть на документацию/ТЗ и на сам код. Самый частый кейс, когда тест рассматривается в качестве документации, если он упадет, тогда описание теста как раз скажет, как работал код.
Полностью согласен с тем, что тесты - это не цель разработки и, тем более, не религия. В статье я хотел сказать, что тесты - это инструмент, который помогает совершать меньше ошибок, и им нужно научиться пользоваться.
Покрыть тестами полностью приложение нельзя, и большим ограничением, чем математика, выступают сроки и требования к системе. Если пишем прошивку для самолета или кардиостимулятора - нужно больше тестов, если у нас лендинг - ему тесты могут и вовсе не нужны. Если же требования допускают вольность, то тут стоит обратиться к договоренностям, чтобы тесты или их отсутствие не стали проблемой
Как уже сказал @ws233 тесты часто похожи, например, если у нас есть два сервиса суть которых только делать запрос на бэкенд, но с разными url-ами, то их тесты будут практически копиями. Также часть тестов могут быть параметризированными, если считать их за несколько. А некоторые тесты делаются копированием, например, если проверяем функцию, которая на вход может принять строку, null и undefined, в таком случае два последних кейса будут копией, только разные входные аргументы.
Могут быть и сложные legacy-моменты, когда проще переписать код и только потом написать тесты, или же при написании тестов зависимости настолько запутанны, что их невозможно замокать. В таких случаях написать 5 тестов за день может быть рекордом, но в остальных случаях, можно запросто написать 15-20 тестов без проблем.
Я бы добавил еще вопрос о том, как можно еще обезопасить форму от перебора. И как вариант - capcha при нескольких неправильных попытках входа. Также можно следить за количеством неудачных попыток (или количеством попыток входа в секунду или за промежуток времени) и вводить какое-то временное ограничение на вход, например "следующую попытку входа можно осуществить через 5 минут"
Помню, как решал подобную проблему, была таблица, и в каждой строке было выпадающее меню, которое подписывалось на событие resize и scroll для закрытия (писали на Angular без использования onPush). При 10-20 записях все было хорошо, но при 100 записях все начинало тормозить, любое событие resize или scroll вызывало фриз на 1,7-1,8 секунды. Договорился с аналитиками, что можно заменить все на css, принеся в жертву открытие на клик мыши. Стало работать за 2-3мс. (Сейчас я бы там все переписал по нормальному, но тогда это было тоже крутое ускорение)
Как вариант можно циклом вычислять разницу, способ конечно примитивный, но работать будет.
let sub = function(a,b){
let result = 0;
let start = b;
let end = a;
if (a >= b) {
for (let i = start; i<end; i++) {
result++;
}
}
else {
for (let i = end; i<start; i++) {
result--;
}
}
return result;
}
Весьма интересна ситуация, когда автомобиль попадает из одной страны в другую, где разнонаправленные движения. Из Франции (правостороннее) автомобиль через паромную переправу попадает в Англию (левостороннее). И если автопилот обучается, то что с ним будет при таком переходе, если для человека такой переход может быть сложен и привести к неочень хорошим последствиям?
В принципе идея хорошая, правда конечно она не спрогнозирует целый ряд правонарушений, такие как хакерские атаки и тому подобное. Но, в принципе, имея довольно большую статистику, хороший алгоритм обработки этих данных, а если повезет то и какую-нибудь нейронную сеть, то можно делать довольно большую кучу прогнозов из разных областей.
Каюсь, упустил этот вариант. Спасибо, что натолкнул на этот вариант. Потребовалось некоторое время, чтобы изучить этот вопрос.
Если приложение-компонент одно, не имеет необходимости в общении с внешним сайтом, то очень даже подходит. Я бы сказал, что практически web-component.
Из плюсов
Доступ к window и другим данным родительской страницы как в web component и так же работают css-переменные, можно добиться конфигурирования.
Встраивание аналогично Web-components
Практически закрывает все возможности, что было у web omponents.
Из минусов
Не получилось встроить второе приложение параллельно, Angular не рассчитан на 2 и более инстансов на одной странице.
Также не работает Router
Нельзя динамически создать несколько компонентов (1п)
Нет общения посредством Input-Output, если это необходимо, то придется повозиться.
В остальном, если этот вариант удобен, то почему бы и нет. Можно выбирать вариант под свои потребности любой рабочий вариант.
Сильно подробно не исследовал, скорее всего, что-нибудь еще упустил.
Если HTML5 может любой произвольный тег считать чем-то валидным, то Angular, например, будет пытается распарсить это тег как компонент, не сможет его найти и сломается на этапе билда.
Соглашусь, можно написать нативно. Тогда будет банд маленького размера, ну или как минимум меньше, чем нам достанется от Angular.
Но стоит смотреть на ситуацию под разными углами. Например, форма может уже существовать в рамках другого Angular-приложения. Тогда создать вторую форму на нативных технологиях будет "дороже", как по написанию, так и по поддержке, придётся повторять одну и ту же логику дважды на разных технологиях.
Имея под рукой UI-кит, инструменты для работы с формами и т.д., можно ускориться в процессе разработки, что тоже важно. А также готовые и проверенные инструменты уберегут нас от мелких проблем, таких как, например, баги кроссбраузерной верстки.
Также стоит смотреть в сторону дальнейшего развития функционала. Сегодня у нас два поля и кнопка, а завтра это может быть форма со степпером или другой логикой. Придётся создавать "конструктор форм", что уже будет на порядок сложнее.
Рад, что статья пришлась по душе.
Не часто выпадают такие задачи, поэтому, в целом, не было понимания на каком уровне находятся web components. Очень классный и мощный инструмент, но все же имеет свои плюсы и минусы. Так что все равно приходится подбирать инструмент под задачи. Тот же Youtube встраивает свои видео через iframe.
Вместе с 17 версией документация перешла на новый домен и новый сайт. https://angular.dev
Выше уже указали ссылку на новый синтаксис, но тоже продублирую тут: https://angular.dev/guide/templates/control-flow
Сам синтаксис обсуждали в RFC ещё год назад https://github.com/angular/angular/discussions/50719
Чтобы использовать *ngIf нужно импортировать commonModule, или импортировать из него NgIf-директиву. Это не очень удобно, особенно в разрезе standalone-компонентов. А
@ifне требует импорта, это часть синтаксиса шаблона, что убирает ещё один импорт. Про то, что не нужен в некоторых кейсах ng-component, я уже написал.Также, новый синтаксис для for обязывает имеет trackBy, но тут же упрощает его использование, достаточно при описании написать что-то типа `@for(item of items; track item.id)`, и получаем уменьшение перерисовок с привязкой к id-сущности.
С 17 версии Angular появился новый синтаксис в шаблонах
@for,@if,@switch, которые позволяют избежать использования ng-container в описанных выше кейсах. Например, так:В кейсах с ngTemplateOutlet он вполне подходит, а вот вместе с новыми фичами шаблона - стал в большинстве случаев лишним.
Ответ был не Вам, а общим комментарием к статье)
Понятно, что там где нет code-review все будет очень плохо, сам работал без него однажды
Использовать дефолтные настройки не очень правильно, потому что у разработчиков могут быть разные IDE с разными дефолтными настройками. Разумно иметь единый источник правил, чтобы у всех разрабов был единый формат кода (был случай, когда поменял одну строку, но переформатировался весь файл).
"Спецификация дизайн", опечатался немного (спецификация или дизайн-ревью), но подразумевал спецификацию решения, или дизайн ревью решения. Какая-то активность, результатом которой будет описание технического решения, которое устроит остальных разработчиков, системных аналитиков или архитекторов (смотря какая команда)
Кажется разумным автоматизировать все, что можно автоматизировать: линтеры/форматтеры кода и прочие плюшки, которые делают код красивым. Чтобы не тратить на это время при ревью.
Иметь набор договоренностей и стайлгайды, которым следует команда. Но они могут пересматриваться
Делать какую-то спецификацию дизайн разумно, если делается что-то новое. Можно выделить отдельным этапом во флоу разработки, и еще на этапе анализа понять как делать.
Приветствую! Спасибо что заметил баг и не промолчал! Я передал его команде разработки мобильного приложения.
Рекомендую заводить баги через чат поддержки или через обратную связь в мобильном приложении, так точно он попадет к разработчикам раньше)
Именно бизнес-полопёку лучше получать из интеграционных тестов, или е2е-тестов, так как они отображают юзер-кейсы. А вот суть того, как работает конкретный метод/функция можно узнать из юнит-теста. Конечно, в первую очередь стоит смотреть на документацию/ТЗ и на сам код. Самый частый кейс, когда тест рассматривается в качестве документации, если он упадет, тогда описание теста как раз скажет, как работал код.
Полностью согласен с тем, что тесты - это не цель разработки и, тем более, не религия. В статье я хотел сказать, что тесты - это инструмент, который помогает совершать меньше ошибок, и им нужно научиться пользоваться.
Покрыть тестами полностью приложение нельзя, и большим ограничением, чем математика, выступают сроки и требования к системе. Если пишем прошивку для самолета или кардиостимулятора - нужно больше тестов, если у нас лендинг - ему тесты могут и вовсе не нужны. Если же требования допускают вольность, то тут стоит обратиться к договоренностям, чтобы тесты или их отсутствие не стали проблемой
Как уже сказал @ws233 тесты часто похожи, например, если у нас есть два сервиса суть которых только делать запрос на бэкенд, но с разными url-ами, то их тесты будут практически копиями. Также часть тестов могут быть параметризированными, если считать их за несколько. А некоторые тесты делаются копированием, например, если проверяем функцию, которая на вход может принять строку, null и undefined, в таком случае два последних кейса будут копией, только разные входные аргументы.
Могут быть и сложные legacy-моменты, когда проще переписать код и только потом написать тесты, или же при написании тестов зависимости настолько запутанны, что их невозможно замокать. В таких случаях написать 5 тестов за день может быть рекордом, но в остальных случаях, можно запросто написать 15-20 тестов без проблем.
Я бы добавил еще вопрос о том, как можно еще обезопасить форму от перебора. И как вариант - capcha при нескольких неправильных попытках входа. Также можно следить за количеством неудачных попыток (или количеством попыток входа в секунду или за промежуток времени) и вводить какое-то временное ограничение на вход, например "следующую попытку входа можно осуществить через 5 минут"
Помню, как решал подобную проблему, была таблица, и в каждой строке было выпадающее меню, которое подписывалось на событие resize и scroll для закрытия (писали на Angular без использования onPush). При 10-20 записях все было хорошо, но при 100 записях все начинало тормозить, любое событие resize или scroll вызывало фриз на 1,7-1,8 секунды. Договорился с аналитиками, что можно заменить все на css, принеся в жертву открытие на клик мыши. Стало работать за 2-3мс. (Сейчас я бы там все переписал по нормальному, но тогда это было тоже крутое ускорение)