ES
Size: a a a
2021 May 05
АП
Я в целом согласен, но есть и такое мнение: https://github.com/goldbergyoni/nodebestpractices#-212-always-await-promises-before-returning-to-avoid-a-partial-stacktrace
ББ
То есть, исходя из примера мне необходимо убрать async в модели-сервисе-контроллере и использовать связку async/await только там где мне необходимо подождать значение?
V
А
return await в try-catch, когда нужно пробросить другой тип ошибки наверх, а данные вернуть неизменными?ББ
на эту тему я нашел только такую статью https://jakearchibald.com/2017/await-vs-return-vs-return-await/
OS
именно так
ББ
Понял, спасибо за ответы)
ES
да, в том месте норм
AL
ну такое. Лишний микротаск не сделает твое приложение медленным. Мы наоборот юзаем return await везде как код-стайл. Промисы без await спереди мы юзаем в тех случаях, когда хотим явно показать, что мы их не ждем.
ES
просто чаще всего это признак того что человек не совсем хорошо понимает как async работает
AM
подскажите, кто работал с auth0,
каким образом можно в Rules получить language который был в браузере?
в контексте нашел только userAgent и country
каким образом можно в Rules получить language который был в браузере?
в контексте нашел только userAgent и country
АБ
А за счет чего возникает лишний микротаск в этом примере?
IK
Await перед return
АБ
Не после? Если можно, буду благодарен за подробное объяснение, за счет чего аткой возврат увеличивает количество тиков до разрешения, чем передача самого результата(если я правильно понял)
IK
в смысле "после" (перед - в контексте выполнения)
IK
потому что создается еще одна обертка над промисом
ES
когда в обьявлении функции написано async function то эта функция заворачивает все что из нее возвращается в промис, если оно не является промисом. async function test() { return 123 } завернет 123 в промис и вернет его
IK
я кстати тоже последнее время пишу return await чтоб стек в нужное место смотрел
A
это не оптимизируется нодой?