В основном банальные советы, местами очень спорные. Почему это ngrx очень желателен? Без него прекрасно можно жить. Почему использовать material? Каждый раз как с ним столкнусь испытываю ужасную неприязнь. Насчёт использовать lodash вообще молчу, это вообще не имеет отношения к ангуляру, и не является хорошим советом, ибо очень сильно не всегда нужен
Я просто не соглашусь, многие us продукты имеют ужасный дизайн, часто на него как раз не тратят сил и времени. Yahoo eBay, например. У Facebook возможно худший ux из всех возможных, инста туда же, портят не переставая. При этом отечественные, например, банковские приложения - часто очень даже хороши. На примере команды где работаю сам тоже могу сказать, хороший дизайн и удобство пользователя стоят явно не на последнем месте. Есть не очень удачные примеры по ux,вроде 1с, и весьма неплохие вроде контура. Так что не в стране производства дело, кмк
На самом деле, структурная директива тоже есть. Но она не всегда решает поставленную задачу полностью. Если нужно именно скрыть часть UI, то да, но помимо этого есть необходимость определять input свойства дочерних компонент, не скрывая их целиком.
Спасибо. Трудно назвать это статьёй, скорее заметка. На самом деле прямо в процессе работы решил написать, так как функция, кажется не очень популярная, но весьма полезная.
Возможный вариант — написать custom schematics, которые расширят поведение стандартных ng generate. И помимо обычной работы будут еще искать ближайший public-api и в него добавлять экспорты.
В одной конторе, не будем называть ее, даже при офисной работе есть региональный коэффициент, который может скорректировать ЗП от Мск до иных городов миллионников на 50%. При этом, в условном мухосранске может сидеть лидер команды (а так и есть чаще всего, так как ядро разработки начиналось не Москве или Питере), а в мск — исполнитель, на условно одинаковых должностях.
Не могу полностью согласиться, мне как раз нравится что все что нужно идет из коробки, по желанию можно добавить NgRx. Надеюсь что они доведут treeshaking до ума, и тогда большой размер исходного ангуляра станет меньшей проблемой. А так работа с ним пока не доставляла каких-то огорчений.
Далее для каждой строки применяем регулярки, чтобы избавиться от номеров строк и прочего шума.
Стек трейсы сравниваем построчно на первые N строк.
Я так понимаю номера строк выкидываются из-за разных версий сервисов. А если логи раскидать по версиям софта, тогда одинаковые stacktrace будут одинаковы полностью, что может сделать систему сбора еще более продуктивной, как мне кажется
Можете, пожалуйста, подробнее описать как групировали схожие stacktrace? Это вручную делалось, или есть какая-то эвристика помимо регулярок?
Насколько меньше багов стало долетать до прода, в процентах, за более или менее продолжительное время?
Теперь я вас понял. То есть вы не web-components голые используете, а angular elements. У нас была попытка напилить чистые web components, а потом их прикручивать в разные проекты. Там как раз возникала необходимость прикручивать полифилы, которые ломали производительность, переопределяли полифилы «хостового» проекта и т.д. И если писать компоненты на ваниле, то там писать руками приходится ну оочень много.
В основном банальные советы, местами очень спорные. Почему это ngrx очень желателен? Без него прекрасно можно жить. Почему использовать material? Каждый раз как с ним столкнусь испытываю ужасную неприязнь. Насчёт использовать lodash вообще молчу, это вообще не имеет отношения к ангуляру, и не является хорошим советом, ибо очень сильно не всегда нужен
Материал изначально ужасен
Ощущение, что попросили чатгпт текст написать
Если честно, не понятна задача, можете уточнить? И задачу, и как решали?
Ну да, вот в документации не густо https://angular.io/api/forms/ControlContainer
И ещё забыл. Многие продукты Яндекс, nginx, ide от jetbrains сделаны у нас, и вызывают приятные чувства. Дополните список, кто что вспомнит.
Я просто не соглашусь, многие us продукты имеют ужасный дизайн, часто на него как раз не тратят сил и времени. Yahoo eBay, например. У Facebook возможно худший ux из всех возможных, инста туда же, портят не переставая. При этом отечественные, например, банковские приложения - часто очень даже хороши. На примере команды где работаю сам тоже могу сказать, хороший дизайн и удобство пользователя стоят явно не на последнем месте. Есть не очень удачные примеры по ux,вроде 1с, и весьма неплохие вроде контура. Так что не в стране производства дело, кмк
На самом деле, структурная директива тоже есть. Но она не всегда решает поставленную задачу полностью. Если нужно именно скрыть часть UI, то да, но помимо этого есть необходимость определять input свойства дочерних компонент, не скрывая их целиком.
Спасибо. Трудно назвать это статьёй, скорее заметка. На самом деле прямо в процессе работы решил написать, так как функция, кажется не очень популярная, но весьма полезная.
Насколько я понимаю, как минимум material стал частью ангуляра, про сторонние компоненты понятно, что ситуация таже
Я так понимаю номера строк выкидываются из-за разных версий сервисов. А если логи раскидать по версиям софта, тогда одинаковые stacktrace будут одинаковы полностью, что может сделать систему сбора еще более продуктивной, как мне кажется
Можете, пожалуйста, подробнее описать как групировали схожие stacktrace? Это вручную делалось, или есть какая-то эвристика помимо регулярок?
Насколько меньше багов стало долетать до прода, в процентах, за более или менее продолжительное время?