Комментарии 12
Есть такой приём, называется event delegation. Он использовался еще во времена jQuery. Позволяет избежать лишних обработчиков событий, а также сложностей с тем, чтобы эти обработчики навешивать и убирать. Один обработчик сразу на все несколько тысяч элементов.
да и в ангуляре тоже можно, вот пример stackblitz.com/edit/angular-ivy-ctk18j
Видимо речь о том, что в Ангуляре нельзя из event.target получить экземпляр компонента, в котором произошло событие. В моем примере для этого используется data-аттрибут, который сохраняет индекс компонента, и по этому индексу забирается инстанс из QueryList. И нельзя сказать что это «универсальный способ».
А как насчёт делегирования событий? Для этого нужно самостоятельно реализовывать дополнительные механизмы, в Angular нет универсального способа решения этой задачи.
Видимо речь о том, что в Ангуляре нельзя из event.target получить экземпляр компонента, в котором произошло событие. В моем примере для этого используется data-аттрибут, который сохраняет индекс компонента, и по этому индексу забирается инстанс из QueryList. И нельзя сказать что это «универсальный способ».
Хммм… Фреймворки точно делают чтобы было проще писать приложения?
вопрос в сложности приложения.
Фреймворк позволяет прибегать к однообразным паттернам и удобно разделять функционал.
Эта задача, если ее представить в независимом, рафинированном виде при помощи фреймворка решается сильно громоздко, но в составе сложного приложения такой код будет уже предпочтительней js-лапше на эвентах.
Ну и нельзя отрицать что конкретно этот кейс не очень хорошо ложится на ангуляр и ts.
Если бы, допустим, забить на типизацию, можно было бы сделать ссылку на инстанс полем хтмл-элемента и получать из таргета напрямую.
А еще я могу оформить все это дело в виде либы с директивой, и в живом коде (там, где логика) все это будет спрятано под короткую запись в шаблоне.
Фреймворк позволяет прибегать к однообразным паттернам и удобно разделять функционал.
Эта задача, если ее представить в независимом, рафинированном виде при помощи фреймворка решается сильно громоздко, но в составе сложного приложения такой код будет уже предпочтительней js-лапше на эвентах.
Ну и нельзя отрицать что конкретно этот кейс не очень хорошо ложится на ангуляр и ts.
Если бы, допустим, забить на типизацию, можно было бы сделать ссылку на инстанс полем хтмл-элемента и получать из таргета напрямую.
А еще я могу оформить все это дело в виде либы с директивой, и в живом коде (там, где логика) все это будет спрятано под короткую запись в шаблоне.
Я скорее к тому, что если фреймворк для решения довольно простой задачи вынуждает использовать намного более сложный путь с кучей оверинжениринга (а навешивание и удаление хэндлеров событий при помощи intersection observer вместо того, чтобы сделать делегирование выглядит крайним овериженирингом), то что-то идет не так.
а как делегировать mouseenter? it doesn't bubble.
Можно было конечно через mouseover сделать, не факт что оно работает с tippy.
Но честно говоря не вижу разницы. Директива пишется один раз и потом можно забыть как оно устроено.
Можно было конечно через mouseover сделать, не факт что оно работает с tippy.
Но честно говоря не вижу разницы. Директива пишется один раз и потом можно забыть как оно устроено.
Я скорее к тому, что если фреймворк для решения довольно простой задачи
Это не задача — это решение. И если это решение плохо реализуется во фреймворке — значит, просто, это решение считается плохим.
Решаю похожую задачу, есть подозрение, что вешать на каждый элемент свой Intersector — не очень хорошая затея.
Вероятно, его нужно вытащить в единый сервис, а не применять на каждом элементе функцию inView()
Кроме того, не пробрасывая root-контейнер, тоже можно как-то повлиять на производительность, не зря ведь в options к созданию обсервера его можно задавать.
Есть у кого точная информация на этот счёт? Можно ли использовать решение в лоб, как описано в статье?
Тоже ниже вопрос по производительности поднял. Списался и c автором оригинальной статьи, в итоге добавил в свою библиотеку поддержку одного обзёрвера на много элементов, так что можно подключать и юзать :)
github.com/ng-web-apis/intersection-observer
github.com/ng-web-apis/intersection-observer
Пользуясь случаем чуток прорекламирую наш опенсорс. Мы пилим легковесные обёртки над нативным API под Angular и у нас есть как раз Intersection Observer, обёрнутый в Observable сервис:
github.com/ng-web-apis/intersection-observer
Отлично подойдёт для подобного кейса. Интересно ещё, насколько выгоднее иметь 700 обзёрверов против 700 ивент листенеров. Можно было бы эту тему оптимизировать, ведь параметры одинаковые — можно в одном обзёрвере отслеживать все 700 элементов и эмитить наружу какие элементы сейчас видимы. Ну и сделать из этого сервис, доступный всем элементам.
github.com/ng-web-apis/intersection-observer
Отлично подойдёт для подобного кейса. Интересно ещё, насколько выгоднее иметь 700 обзёрверов против 700 ивент листенеров. Можно было бы эту тему оптимизировать, ведь параметры одинаковые — можно в одном обзёрвере отслеживать все 700 элементов и эмитить наружу какие элементы сейчас видимы. Ну и сделать из этого сервис, доступный всем элементам.
Скажите пожалуйста, вы рассматривали создание экземпляра tippy при наведение на элемент на котором висит директива? Ведь тогда даже для видимых элементов не нужно было бы создавать экземпляры, но могут быть проблемы с задержкой при инициализации(тултип появляется не сразу).
А где отписка от
inView(this.host.nativeElement).subscribe (в ngOnDestry)?Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Отложенное применение функционала директив в Angular