Можно переписать строчку, которая берёт путь из DI, чтобы она использовала спрайт и доставала символ. В приложении, где разных иконок не пара сотен загружать их все разом будет и правда не слишком накладно.
Да, я тоже часто качаю с flaticon. Если у тебя SVG иконка-кнопка, например, и при наведении ты хочешь поменять её цвет, то нужно как-то уметь это делать через CSS. В статье описано, как это можно сделать, не прибегая к шрифту из иконок.
Ну я на слух говорю. Померил через console.time — время, между регистрацией события и запуском аудио буфера на воспроизведение (т.е. накладные расходы от ангуляра с его байндингами, RxJS и декларативного веб аудио) обычно порядка 5мс:
Так что остальное — input latency, обусловленное реализацией Web MIDI API в Chromium. А сколько там его я затрудняюсь померить :)
Да, что-то вроде того. На самом деле, довольно быстро привыкаешь. Эта задержка сравнима с задержкой, скажем, в игре Rocksmith, если слышали о такой. Профессиональных музыкантов напрягает, обычно от 20-30мс, тут уж ничего не поделаешь.
Тоже ниже вопрос по производительности поднял. Списался и c автором оригинальной статьи, в итоге добавил в свою библиотеку поддержку одного обзёрвера на много элементов, так что можно подключать и юзать :) github.com/ng-web-apis/intersection-observer
Только что немного обновил код, вынеся логику в директиву. А что не так с динамическим созданием? Можешь показать пример с кодом, где это нужно и как оно нужно?
Ну тут без работы со свойствами nativeElement никак. Мне кажется довольно прозрачно и наглядно получилось, в целом немного императива. Вообще я думал, что через директиву будет запутаннее для статьи, поэтому не стал её делать, но сейчас переписал на директиву и стало совсем классно (через один аутпут из fromEvent): stackblitz.com/edit/angular-scrollbar-component-directive?file=src/app/scrollbar/draggable.directive.ts
Спасибо за коммент :) Добавлю в статью.
Честно говоря, не очень понимаю, в чём преимущество тянуть ползунок, по сравнению с тянуть контент на телефоне, но поскольку это кастомный скроллбар, тут, как раз, такое поведение вполне можно реализовать, просто задачи такой не стояло. Возможно достаточно будет заменить события мышки на тачи и, соответственно, координаты будут браться по другому. Возможно как-то иначе. В любом случае, это просто DIV`ы, на которых слушаются события и сделать можно всё, что хочется.
Пользуясь случаем чуток прорекламирую наш опенсорс. Мы пилим легковесные обёртки над нативным API под Angular и у нас есть как раз Intersection Observer, обёрнутый в Observable сервис: github.com/ng-web-apis/intersection-observer
Отлично подойдёт для подобного кейса. Интересно ещё, насколько выгоднее иметь 700 обзёрверов против 700 ивент листенеров. Можно было бы эту тему оптимизировать, ведь параметры одинаковые — можно в одном обзёрвере отслеживать все 700 элементов и эмитить наружу какие элементы сейчас видимы. Ну и сделать из этого сервис, доступный всем элементам.
Конфигурация через DI хороша там, где оно не меняется. Через параметры вызова там, где меняется часто. Можно и совмещать эти два подхода. Что-то типа persistent config с возможностью переопределить в отдельных случаях. Пример такого подхода можно увидеть у нас в ng-dompurify — либы для использования DOMPurify в качестве санитайзера Angular: https://habr.com/ru/company/tinkoff/blog/459396/
В ТС, кончено, всё точно так же. Код этот написан так, просто чтобы кратко показать, что оно работает на коллбэках. Автору статьи, уверен, и в голову не пришло, что кто-то станет читать статью про Ангуляр и обзёрваблы не зная, как работает this в таких ситуациях. Это всё равно, как докопаться, что там в коде функция doSomething в итоге глобальная, а значит либо оно совершенно бесполезное, либо адовый сайдэффект.
Мы традиционно пишем Inject всегда, так как хуже от него не будет. В Ivy, наверное, это делать уже не нужно, но изначально пошло вроде вот почему. В старых версиях Angular чтобы это дело работало без Inject в JIT при локальной разработке надо было делать emitDecoratorMetadata: true. При этом он записывал типы параметров и клал их реально в код. Это ломало Angular Universal, в котором на бэке не было всех этих классов и при SSR оно падало с каким-нибудь reference KeyboardEvent is undefined. Надо будет эту тему освежить, как раз сейчас занимаюсь созданием пакета под Angular Universal.
Поскольку везде, где этот сервис будет использоваться его можно типизировать, как Observable, тут как раз зависимость «is a», а не «has a», поэтому принципы ООП наследование не нарушает и под BaseBean не подпадает.
Ну разделение на изолированные компоненты с входными данными, инкапсуляция стилей, то, как лучше всего внутреннюю организацию компонентов сделать, шаблоны и кастомизация внешнего вида. Я работаю над библиотекой UI компонентов и если добавить в веб компоненты DI и проверку изменений, то практически всё, что я делаю можно без особого труда в них перенести не сильно меняя код.
У меня, тогда, встречный вопрос:
Если не нужно что-то такое, о чём разработчики ангуляра не подумали за вас. И да, если вы развиваетесь так, как они придумали и всегда можете объяснить бизнесу «вот эта штучка противоречит политике фреймворка, так что нет»
Можете привести пример штук, противоречащих политике фреймворка? Я бы сказал, чо разработчики Ангуляр подумали за нас только в очень глобальных вопросах, скажем, в роутинге, в остальных же случаях они оставили нам полную свободу действий и я не могу сходу назвать ситуацию, которую вы озвучили.
Можно переписать строчку, которая берёт путь из DI, чтобы она использовала спрайт и доставала символ. В приложении, где разных иконок не пара сотен загружать их все разом будет и правда не слишком накладно.
Для оптимизации ещё могу kraken.io посоветовать, но вы, наверное, уже про него знаете :-)
Так что остальное — input latency, обусловленное реализацией Web MIDI API в Chromium. А сколько там его я затрудняюсь померить :)
github.com/ng-web-apis/intersection-observer
stackblitz.com/edit/angular-scrollbar-component-directive?file=src/app/scrollbar/draggable.directive.ts
Спасибо за коммент :) Добавлю в статью.
github.com/ng-web-apis/intersection-observer
Отлично подойдёт для подобного кейса. Интересно ещё, насколько выгоднее иметь 700 обзёрверов против 700 ивент листенеров. Можно было бы эту тему оптимизировать, ведь параметры одинаковые — можно в одном обзёрвере отслеживать все 700 элементов и эмитить наружу какие элементы сейчас видимы. Ну и сделать из этого сервис, доступный всем элементам.
Конфигурация через DI хороша там, где оно не меняется. Через параметры вызова там, где меняется часто. Можно и совмещать эти два подхода. Что-то типа persistent config с возможностью переопределить в отдельных случаях. Пример такого подхода можно увидеть у нас в ng-dompurify — либы для использования DOMPurify в качестве санитайзера Angular:
https://habr.com/ru/company/tinkoff/blog/459396/
В ТС, кончено, всё точно так же. Код этот написан так, просто чтобы кратко показать, что оно работает на коллбэках. Автору статьи, уверен, и в голову не пришло, что кто-то станет читать статью про Ангуляр и обзёрваблы не зная, как работает this в таких ситуациях. Это всё равно, как докопаться, что там в коде функция doSomething в итоге глобальная, а значит либо оно совершенно бесполезное, либо адовый сайдэффект.
Это пример того, как работает НАТИВНЫЙ API.
У меня, тогда, встречный вопрос:
Можете привести пример штук, противоречащих политике фреймворка? Я бы сказал, чо разработчики Ангуляр подумали за нас только в очень глобальных вопросах, скажем, в роутинге, в остальных же случаях они оставили нам полную свободу действий и я не могу сходу назвать ситуацию, которую вы озвучили.