Упрощаем работу с Angular с помощью @taiga-ui/cdk: 5 наших лучших практик

[essome]

Не рассматривали вместо destroy service until destroy? Там поудобнее будет

[MarsiBarsi]

Рассматривали с давних времен, следим за развитием, но к себе не берем.

Until-destroy завязывается на внутреннюю реализацию Ангуляра, использует приватное API и императивно патчит его сущности. Такие штуки могут ломаться от неожиданного апдейта ангуляра (там и сейчас разные реализации для Ivy и View Engine), могут взорваться при неожиданном желании собраться в SSR или Ionic. Мы к такому не готовы и стараемся выбрать Angular Way везде, где это возможно. Вот в этих двух файлах реализация until-destroy с множеством патчинга и вторжением в кухню ангуляра:

https://github.com/ngneat/until-destroy/blob/master/src/lib/until-destroyed.ts

https://github.com/ngneat/until-destroy/blob/master/src/lib/until-destroy.ts

А вот так выглядит наш TuiDestroyService, использующий один лайфсайкл хук и возможности DI в Angular:

https://github.com/TinkoffCreditSystems/taiga-ui/blob/main/projects/cdk/services/destroy.service.ts

Кроме того, наш сервис можно использовать для различных фокусов с DI и отписываться в сервисах/DI-фабриках, если в этом есть нужда. У until-destroy такой возможности нет

[Zy2ba]

Мы у себя на проекте пришли к соглашению по | async, который, как мне видится, лаконичной альтернативой *tuiLet встроенными средствами. На Верхнем уровне описывается такая структурка:

<ng-container
  *ngIf="{
    isSomeFactor: (isSomeFactor$ | async) || altValue,
    someUsefulValue: someUsefulValue$ | async | somePipe 
  } as data"
>
 <!--код компонента-->
</ng-container>

Можно использовать в таком виде даже когда используется только один источник где-то в глубине компонента. Так проще понять какие вообще Observable потребляет компонент, да и расширяется список потребляемого добра легко.

[MarsiBarsi]

Да, такой альтернативный подход тоже неплохая идея, но мы его не используем. В этом случае у нас создается новый JS объект контекста на каждую проверку изменений. В целом, ничего сильно страшного в этом нет, но такие пересборки объектов могут постепенно привести к проблемам с перфомансам в очень больших приложениях (например, мы везде пересоздания объектов выносим в Pure, чтобы все скейлилось как можно дольше). Чтобы в дальшейнем не выискивать довольно хитрое узкое горлышко, мы так не делаем с самого начала.

В целом, хорошая идея для небольшой статьи — замерить такие штуки и определить, на каком масштабе юзера начнут замечать разницу, посмотреть дефолтную стратегию и OnPush

[movl]

@MarsiBarsi, Вы пробовали использовать внутренние управляющие инструкции компилятора для оптимизации tuiLet?

https://github.com/angular/angular/blob/master/packages/common/src/directives/ng_if.ts#L217

На сколько я понял, именно за счет выявления этих конструкций, для выражений формируется менее затратная привязка, что позволяет делать проверку поддерева ngIf, гораздо дешевле

https://github.com/angular/angular/pull/20702/commits/4c47bc431e2e372e6c08ad4f336db76906c3ad63
https://github.com/angular/angular/commit/82bcd83

В общем если у Вас были какие-то расследования на этот счет, не могли бы поделиться, а то от разработчиков уже давно нет никаких ответов

https://github.com/angular/angular/issues/15280#issuecomment-430479166