писать ее через pipe если можно через async/await и toPromise ?
Если ты юзаешь rxJS то зачем портить единый стиль и мешать 2 подхода?
да плевать мне на подход, что от него изменится два там подхода или ожин? мне главное что бы код был быстрочитаемый и понятный
то что ты мешаешь 2 подхода уже делает его более сложным для понимания
async/await очень сложный для понимания, да
Можно еще упростить, зачем использовать http модуль, если можно через fetch, зачем байндить события в шаблоне, если можно найти элемент через querySelector и навестить листенер, зачем использовать ангуляр, если можно на голом js все написать
1. Чтобы легко отменить запрос 2. Чтобы декларативно стартовать запрос, не используя lifecycle 3. Чтобы сделать запрос зависимым от некоторого состояния (фильтрация, пагинация, поиск) 4. Чтобы гибко организовывать таймаут/ретрай
Не забывайте еще о том, что в ангуляре не стоит использовать async/await, без транспиляции в промисы это ломает зону, т.к. они не манкипатчатся
вот это тот ответ который я ждал несколько часов. Большое спасибо а не посмотри доклад, почитай про то что обсы мощнее, узнай отличия промисов от обсов и тд
Это касается только async await, а не промисов в целом, просто техническая деталь. В целом же стоит понимать, что Angular и RxJs неразрывно связаны, если у вас какие-то проблемы с RxJs - то стоит использовать другой фреймворк
а теперь как это связанно с моим гайдом? он же не про обучение.
у меня проблем нету, я умею в rx и в угловой). просто тут скинули бест прэктис и у меня возникли вопросы "почему". спасибо что помогли с 1 разобраться
можно п2 подробнее. не понятно как ркс связан с лайциклом? можно вызывать промисы на любой лайфцикл
через асинк пайп подпишешься в разметке и отвяжешься от лайфцикла
а где тут про обучение? у вас есть тезис "не используйте промисы" а пояснения адекватного нет. не "просто потому что" же. иначе это вкусовщина и вы кое что не понимаете вот и возник ряд вопросов
Методы жизненного цикла - это просто лишний код, который можно не писать. async пайп сделает всё сам, подпишется и отпишется
Что за транспиляция?
тоесть это наоборот в пользу промисов а не ркс, верно?
Async/await -> Promise, для сред, которые нативно не поддерживают async await
Нет, это в пользу rx
а с остальными вопросами поможете?
попробую. но тут от вашей цели зависит. какая у вас цель?
не поспорить, а понять почему это хорошая практика
Не наследуем компоненты между собой. Почему? $ используют для обозначения observable, почему в примерах у вас переменная имеет тип subscription а название uneditable$ ? в целом я к тому что неплохо бы иметь под практиками пояснения почему так а не иначе
То есть в ngOnInit для http request плохо будет использовать async/await?
Я кстати в Тимлида тоже просил больше аргументов почему я так должен делать, а он начал думать что я быкую))
async/await не стоит использовать в ангуляре, т.к. это сломает обнаружение изменений. Промисы - потому что это менее гибко
про $ у меня вроде ничего не написано. а про наследование компонентов там криво работает лайфцикл. + это вроде написано в стайлах ангуляра.
я к тому что в примерах вы разные типы данных в переменную записываете + нарушаете соглашение наследование компонентов у меня в проектах есть и никаких проблем с ними у меня никогда не было
тяжело словами быстро выразить жизненный опыт, который привел к этим выводам. Если бы это было очевидно, то и вопросов бы у вас таких не возникло.
нормально работает как раз
Если вы учёный, квантовый физик, и не можете в двух словах объяснить пятилетнему ребёнку, чем вы занимаетесь, — вы шарлатан.
фейнман - гениальный популяризатор, но не все такие. И да, он 5 летним детям тоже врядли бы объяснил
Ого, я вот уже 3ий раз сталкиваюсь с реализацией наследования от кторой приходиться избавляться из-за сложности поддержки/тестирования и изменения
покажите где разные типы я поправлю. компоненты наследовать плохо. т. к там практически ничего не наследуется. вы наследуете с целью получить логику парента?
практически ничего это как? Да, с lifecycle
Обсуждают сегодня