плохим тоном?
потому что ты к промису приводишь
да понимаю, а почему это плохо?
трудно противостоять желанию упростить код (например убрать пару строк и вложенность заменив подписку с take(1) на await .toPromise() в случае с каким-нибудь диалогом подтверждения
напишу чисто свое мнение 1) твой код становится не однотипным, местами промисы, местами потоки. 2) лично в моей практике возникало, что приходилось дальше по промису еще доп обработку добавлять, пришлось изменять сразу несколько компонент переделывая это на поток(так как промис передавался через несколько сущностей). 3) промисы тяжело отписывать, приходится передавать контроллеры для отмены. И если конкретно сейчас по каким-то непонятным причинам отписка не нужна, то это не значит, что через месяц требования не поменяются и она не понадобится, тогда выполняешь пункт 2 4) у toPromise есть особенность, если ты делаешь toPromise на поток/сабжект, который не комплитится, то промис так и зависнет в состоянии pending. Отсюда, чтобы понять, что промис реально резолвится нормально, надо изучить всю цепочку потоков
Благодарю за развернутый ответ. я почему то был уверен что в случае с .toPromise() а так же с take(1)/first() отписка происхождит автоматически
она происходит, но важно понимать, что она может не успеть произойти на момент, когда данные уже не нужны. Например, компонент был удален. Еще есть нюансы с тестами и HMR. по toPromise нюанс такой, что например подписка на сабжект вернет значение только тогда, когда он будет закомплитен, те опять же надо точно знать, что поток завершается или вызывать тот же take(1), и только потом toPromise
Спасибо! в тестах я вроде решаю за счет fakeAsync. а вообще toPromise использую в случае когда например нужно дождаться закрытия диалога или что то в этом роде. Но я пересмотрю свой подход, благодарю
По отпискам рекомендую: https://medium.com/ngx/why-do-you-need-unsubscribe-ee0c62b5d21f https://www.youtube.com/watch?v=RhYUnc622qg
читал но уже давно, перечитаю пожалуй
Обсуждают сегодня