Подскажите Когда я объявляю переменные внутри метода способом let или var,

какое в них отличие?

И нужно ли после выполнения метода уничтожать переменные? TypeScript умеет делать очистку памяти автоматически?

var - function-scope const/let - block {} scope Используйте const в 95% случаев, потом let, если надо менять переменную, и var, если хотите попасть в ад

а за что в аду горят var? чем плох скоуп на всю функцию?

Потому что это не cool, крутые devs используют new синтаксис А если серьезно, просто забудьте про var, он не нужен уже. Если умеете им пользоваться - пишите, но блочная видимость const/let просто-напросто понятнее. Любой шарпист или джавист разберется с первой секунды, а про var им гуглить придется

Спасибо за разъяснения. А можете еще пояснить как тайпскрипт работает с памятью? Нужно ли мне уничтожать объявленные переменные?

ts не работает с памятью никак - он компилится в js. Переменные уничтожать не надо, а вот обнуление полей в классах видел неоднократно

понял, спасибо А подскажите как лучше сделать У меня 8 типов сущностей. Думаю создавать ли отдельные BehaviorSubject для каждого типа сущностей. Или сделать один BehaviorSubject в котором будет массив сущностей { 1: [array of objects], 2: [array of objects], ... 8: [array of objects], } Какой способ лучше? В каком случае будет BehaviorSubject будет потреблять меньше ресурсов и легче будет найти нужный объект?

Вы сильное переоцениваете влияние решения на производительность Решать будет количество подписок (в т.ч. и rx-операторов в цепочке) и количество эмитов у сабжектов. Если бы была серьезная просадка по производительности, то сделал бы в одном сабжекте, но я не верю, что у вас тот случай Короче, выбирайте удобный вам способ

У меня есть категории, заголовки, комментарии, и еще 5 типов сущностей. Все они загружаются на 1 странице, которая состоит из множества компонент которые подписаны на сабджект. Объектов всего около 10 тыс, но на 1 странице загружается по 100-200 шт. Поэтому подписок выходит много. А еще приложение фоном слушает сокет, и может обновить какой-то объект, который пришел с сервера. В этом случае что может быстрее вызвать просадку по производительности: количество подписок, или большое количество данных в 1 сабджекте?

Количество подписок. Данные всего лишь хранятся в объектах/массивах, с ними ничего особо не происходит, просто ссылки на них бегают туда-сюда, а они копеечные

А вообще есть вкладка performance в devTools, там можете глянуть, что и сколько по времени выполняется

И еще, если данные организованы откровенно всрато, то есть лишние map, for, лишние ивенты в цепочках, то хранение в одном сабжекте может привести к низкой производительности https://www.learnrxjs.io/learn-rxjs/operators/filtering/distinctuntilchanged - думаю, он вам пригодится

У меня с сервера приходит массив объектов. Я сортирую их по типу и при выводе на экран я ищу в цикле те объекты, у которых нужный id или parent_id, это достаточно всрато? Как можно улучшить Спасибо за ссылку, пригодится

Если поиск происходит постоянно, то сделайте map-ы, ключ-значение И еще, может ваш случай как раз, НИКОГДА не делайте байндинг к тяжелым функциям [item]="findItem()", где findItem пробегается по тысяче элементов - так нельзя

мэппинг к сожалению не получится, потому что ключем для поиска может выступать 2 разных поля, а может и другие критерии будут Вот какой алгоритм я сделал: 1) Сортирую по типу выходящие данные, выходит так: { 'categories': [тут массив объектов категорий] 'posts': [тут массив объектов публикаций] } 2) Дальше я подписываюсь в компоненте на сабж, и если пришло изменение, то тут: - Если нужно найти текущий объект категории, тогда циклом ищу в subj.caterories, выхожу break при совпадении - Если нужно найти все дочерние публикации в текущей категории, то тут прохожу по всем объектам в subj.posts и выбираю все у которых parent_id == category.id. И так же с комментариями, изображениями и тд. Получается что поиск происходит при инициализации компонента и при обновлении сабжа. Можно как-то улучшить такой алгоритм?

Если сабжект обновляется нечасто, то я не знаю, что можно сделать Если часто, то distinctUntilChanged или filter вам помогут. Или используйте какую-нибудь реализацию стора (ngrx/ngxs/akita), потому что они и есть большой оптимизированный сабжект

Как я и говорил, сделайте замеры в devTools/performance, посмотрите, что выполняется дольше всего

угу, спасибо за советы, я просто еще не вкурсе как делать замеры, только начал изучать фронт, обязательно разберусь А можете подсказать еще, вот я в каждом компоненте написал subscription.unsubscribe() при ngOnDestroy. Но мне непонятно в каких случаях прекращается подписка. Когда я иду на другой роут? А если на другом роуте те же компоненты, то происходит отписка от старых и подписка заново или продолжит слушать старую подписку тоже? А если у меня компонент открывается при условии *ngIf="!hideComments", тогда при hideComments == false подписка прекратиться?

Почитайте про жизненный цикл компонентов Если компонент отображается через ngIf, то есть удаляется и появляется - компонент пересоздается, весь код в хуках выполняется заново. Роутинг - то же самое, если компонент пропадает из dom, то он умирает, вызывается ngOnDestroy Если на новом роуте те же компоненты - надо смотреть конфигурацию path1/:param1 => MyComponent1------ в таком случае зависит от настроек роутера, по умолчанию он будет использовать тот же компонент и не будет пересоздавать В остальных случаях создастся новый компонент, а старый умрет

это много прояснило, спасибо большое за разъяснения