События, которые стреляют очень часто, например scroll, mousemove, dragmove могут быть хорошими кандидатами на запуск вне зоны. Но чаще всего это всё же requestAnimationFrame.
У нас в компании используются и React, и Angular. Но почти все статьи, в том числе и про библиотеку компонентов, это был Angular (1389 против 231 местных очков вклада в хаб). Так что не знаю, откуда вы взяли про "все прошлые статьи были про React" :)
console.log прописан в стриме test. Он дёргается 2 раза, потому что мы байндим его на data-test и style.height.px. Так же мы от него создаём стрим active, ведь мы его пайпим. Там ещё 2 подписки — на class._active и disabled. Если test записать вот так, то console.log будет один:
1) Так можно указывать более общий тип, чтобы, если что, подменять реализацию — в первой строчке Observable<void> а не TuiDestroyService. Даже надо бы <unknown> написать :)
2) Раньше без этого нельзя было собирать проект без метаданных, что усложняло работу с Universal
3) Токены без этого не подрубишь, а мне нравится единообразие — поэтому пишу всегда одинаково, не думая, токен там или сервис
Да, там 4 разных байндинга, соответственно, 4 разные подписки. Можно порулить через share, но вообще это довольно экстремальный кейс, когда тебе надо на несколько сущностей забайндить один и тот же стрим :)
Боюсь, что по этому не подскажу. API матириала чрезвычайно раздут и сложен в понимании. Мы не ориентировались на него, когда создавали свою библиотеку. Более того, концепция порталов была заложена у нас почти в неизменном виде с самого начала в 2017 году, когда на дворе был Angular 4 и не было Material CDK, и с тех пор служит нам верой и правдой :)
В первую очередь, оборачивание помогает изолировать контекст наложения. Это очень полезно и часто многие фронтендеры про это не знают и пытаются решить проблему вертикальности z-index`ами. Кроме того, в нашем случае оборачивание помогает позиционировать выпадашки — поскольку так мы можем позицинировать их абсолютно и при глобальном скролле их положение не будет скакать. Ну а в случае хинтов и диалогов без враппера не обойтись, ведь там заложена определённая логика для каждого элемента. Это уже не совсем портал в понимании Material CDK, но портал в более общем понимании, когда какой-то элемент мы показываем не в том месте в DOM, где он определён.
Root ещё подключает наши плагины (подробнее о них тут). Некоторые компоненты на это полагаются, так что лучше root подрубить, всё-таки, хотя бы модуль :)
Имеется ввиду не rtl, а именно выравнивание. По дизайну было задумано такое поведение в табличном представлении, но в будущем добавим возможность задания выравнивания. Так же был запрос от англоязычных пользователей, чтобы знак валюты можно было ставить до суммы. Если у вас есть ещё какие-то конкретные предложения и замечания — забегайте в наш гитхаб :)
Спасибо. Интересное решение. Пока не встречал у себя необходимости чистки кэша. С ходу, вроде как, идёт в разрез с моим представлением об использовании подобных методов. Я бы это сделал через протухающий стрим, всё-таки.
Сначала я специально так сделал, чтобы кто-то случайно не повесил декоратор на "грязную" функцию и не получил неожиданный результат. Но потом я понял, что часто из this берутся какие-нибудь сервисы или константы, прилетевшие из DI, которые не меняются. Так что просто добавил .apply(this, args). Кроме того, вариант этого декоратора из @taiga-ui/cdk ещё можно вешать на геттеры для реализации паттерна отложенных вычислений. Вот его исходный код, ставьте из npm и пользуйтесь на здоровье :) https://github.com/TinkoffCreditSystems/taiga-ui/blob/main/projects/cdk/decorators/pure.ts
Я уже не представляю, как на Ангуляре без него что-то писать, очень часто пригождается.
Именно об этом я и говорю. По принципам фреймворка данные движутся сверху вниз, события снизу вверх. Если вам нужно перерендерить дочерние компоненты, а при этом их входные данные не поменялись — вы делаете что-то не по канонам Angular. У самого был подобный кейс. Поведением внутреннего компонента управляла расположенная выше по дереву директива, чтобы избежать пробрасывания инпутов. Вложенный компонент брал её из DI. Решил я эту задачу добавлением стрима: readonly refresh$: Observable<void> = new Subject();
Директива делала next в него в ngOnChanges, а нижестоящий компонент запускал по этому стриму проверку изменений. Возможно вам такой паттерн тоже подойдёт.
Ну а программное изменение инпутов компонента — это проделки Императора, смотрите совет №5 :)
OnPush всё равно работает с зоной, от неё нет нужды отказываться. Нужно для начала избавиться от всех мутаций данных. А там посмотреть, если где-то не подцепляются изменения — нужно капнуть почему. Чаще всего там что-то изменяется в асинхронных коллбэках. Можно пройтись по всем subscribe, setTimeout, setInterval и тому подобному и глянуть, можно ли там перейти на async пайп в шаблоне. Если нет, то надо заинжектить ChangeDetectorRef и сделать на нём markForCheck().
Если у тебя нативный элемент то да, но если у тебя там компонент, то template reference variable будет ссылаться на его инстанс, а не на его DOM элемент.
Столько лет на Хабре нельзя было встроить стэкблитц и спустя всё это время они не утрудились даже сделать, чтобы он загружал их только при доскролле. Даже в спойлере грузит сразу и плевать хотел на аргументы стэкблица «запускать по клику»… :(
Спасибо на добром слове! В данном случае основное отличие в том, что Attribute доступен в конструкторе, в то время, как значения из инпута придут только когда Ангуляр начнёт цикл проверки изменений (ngOnChange/ngOnInit). Так как нам эти значение нужны уже в конструкторе подходит только атрибут или DI. Второе отличие, которое я могу придумать — так не создаётся байндинг и Ангуляру не придётся за ним следить, но я сомневаюсь, что оно хоть как-то мало-мальски значимо сказывается на производительности.
События, которые стреляют очень часто, например scroll, mousemove, dragmove могут быть хорошими кандидатами на запуск вне зоны. Но чаще всего это всё же requestAnimationFrame.
У нас в компании используются и React, и Angular. Но почти все статьи, в том числе и про библиотеку компонентов, это был Angular (1389 против 231 местных очков вклада в хаб). Так что не знаю, откуда вы взяли про "все прошлые статьи были про React" :)
Спасибо, поправил!
strictInputTypes отключит везде, а не точечно :)
Не, deprecated конкретная перегрузка, на которую он по ошибке проваливается, если писать
startWith(null).console.logпрописан в стримеtest. Он дёргается 2 раза, потому что мы байндим его наdata-testиstyle.height.px. Так же мы от него создаём стримactive, ведь мы его пайпим. Там ещё 2 подписки — наclass._activeиdisabled. Еслиtestзаписать вот так, тоconsole.logбудет один:Проблем тут будет не больше, чем при любом другом использовании RxJS :)
1) Так можно указывать более общий тип, чтобы, если что, подменять реализацию — в первой строчке
Observable<void>а неTuiDestroyService. Даже надо бы<unknown>написать :)2) Раньше без этого нельзя было собирать проект без метаданных, что усложняло работу с Universal
3) Токены без этого не подрубишь, а мне нравится единообразие — поэтому пишу всегда одинаково, не думая, токен там или сервис
Да, там 4 разных байндинга, соответственно, 4 разные подписки. Можно порулить через
share, но вообще это довольно экстремальный кейс, когда тебе надо на несколько сущностей забайндить один и тот же стрим :)Боюсь, что по этому не подскажу. API матириала чрезвычайно раздут и сложен в понимании. Мы не ориентировались на него, когда создавали свою библиотеку. Более того, концепция порталов была заложена у нас почти в неизменном виде с самого начала в 2017 году, когда на дворе был Angular 4 и не было Material CDK, и с тех пор служит нам верой и правдой :)
В первую очередь, оборачивание помогает изолировать контекст наложения. Это очень полезно и часто многие фронтендеры про это не знают и пытаются решить проблему вертикальности z-index`ами. Кроме того, в нашем случае оборачивание помогает позиционировать выпадашки — поскольку так мы можем позицинировать их абсолютно и при глобальном скролле их положение не будет скакать. Ну а в случае хинтов и диалогов без враппера не обойтись, ведь там заложена определённая логика для каждого элемента. Это уже не совсем портал в понимании Material CDK, но портал в более общем понимании, когда какой-то элемент мы показываем не в том месте в DOM, где он определён.
Root ещё подключает наши плагины (подробнее о них тут). Некоторые компоненты на это полагаются, так что лучше root подрубить, всё-таки, хотя бы модуль :)
Имеется ввиду не rtl, а именно выравнивание. По дизайну было задумано такое поведение в табличном представлении, но в будущем добавим возможность задания выравнивания. Так же был запрос от англоязычных пользователей, чтобы знак валюты можно было ставить до суммы. Если у вас есть ещё какие-то конкретные предложения и замечания — забегайте в наш гитхаб :)
Спасибо. Интересное решение. Пока не встречал у себя необходимости чистки кэша. С ходу, вроде как, идёт в разрез с моим представлением об использовании подобных методов. Я бы это сделал через протухающий стрим, всё-таки.
Сначала я специально так сделал, чтобы кто-то случайно не повесил декоратор на "грязную" функцию и не получил неожиданный результат. Но потом я понял, что часто из this берутся какие-нибудь сервисы или константы, прилетевшие из DI, которые не меняются. Так что просто добавил
.apply(this, args). Кроме того, вариант этого декоратора из @taiga-ui/cdk ещё можно вешать на геттеры для реализации паттерна отложенных вычислений. Вот его исходный код, ставьте из npm и пользуйтесь на здоровье :)https://github.com/TinkoffCreditSystems/taiga-ui/blob/main/projects/cdk/decorators/pure.ts
Я уже не представляю, как на Ангуляре без него что-то писать, очень часто пригождается.
Именно об этом я и говорю. По принципам фреймворка данные движутся сверху вниз, события снизу вверх. Если вам нужно перерендерить дочерние компоненты, а при этом их входные данные не поменялись — вы делаете что-то не по канонам Angular. У самого был подобный кейс. Поведением внутреннего компонента управляла расположенная выше по дереву директива, чтобы избежать пробрасывания инпутов. Вложенный компонент брал её из DI. Решил я эту задачу добавлением стрима:
readonly refresh$: Observable<void> = new Subject();Директива делала
nextв него вngOnChanges, а нижестоящий компонент запускал по этому стриму проверку изменений. Возможно вам такой паттерн тоже подойдёт.Ну а программное изменение инпутов компонента — это проделки Императора, смотрите совет №5 :)
OnPushвсё равно работает с зоной, от неё нет нужды отказываться. Нужно для начала избавиться от всех мутаций данных. А там посмотреть, если где-то не подцепляются изменения — нужно капнуть почему. Чаще всего там что-то изменяется в асинхронных коллбэках. Можно пройтись по всемsubscribe,setTimeout,setIntervalи тому подобному и глянуть, можно ли там перейти наasyncпайп в шаблоне. Если нет, то надо заинжектитьChangeDetectorRefи сделать на нёмmarkForCheck().