Еще добавлю, есть правило no-return-await в eslint. Еще этот await не совсем бесполезный, он помогает более информативный стек вызова функций получить. В том правиле eslint как раз написано об этом в соучаях когда не надо использовать это правило
В принципе да, но если вы его не пропишете то вы просто потеряете часть стектрейса. И если get запрос выдаст ошибку вы не получите точное место откуда она пришла, a место где было обнаружено не выполненный промис.
Что за бред. Функция возвращает промис, ты ее парсишь через await, но в итоге то функция async автоматом твой распарсенный результат обварачивает в дополнительный промис.
убирайте await и потом ловите рандомные баги, когда у вас не обрабатывается корректно промис =) если метод асинхроннный то ты его вызываешь через await. если вам влом писать букавы, то можете попробовать python например. с таким успехом можно и от ключевых слов const и let можно отказаться, всё равно переменные будут создаваться и так, какая разница
Я ни где не говорю, что нужно не писать await вообще, но если асинхронная функция возвращает асинхронную функцию, то достаточно await только один раз написать, если мы не хотим внутри ловить ошибку. Вам даже Webstorm подсветит это как замечание.
@@PurpleSchool не убирать await даже когда вы не обрабатываете исключение. Это плохая практика... Экономия копейки, а отладка в случае проблем будет затруднена.
@@PurpleSchool Ты получишь другой стек вызовов. Из lint это правило убрали, потому что оно в основном вредное. Более того они пишут что сейчас как раз оставлять будут работать быстрее.
Если хотите детально изучить JS, то переходите на purpleschool.ru
Да, даже webstorm подсказывает, что нужно убирать await. Просто если не убрать, будет выглядеть примерно как: await await.
👍
Еще добавлю, есть правило no-return-await в eslint. Еще этот await не совсем бесполезный, он помогает более информативный стек вызова функций получить. В том правиле eslint как раз написано об этом в соучаях когда не надо использовать это правило
👍
Ну да, а async Пушкин убирать будет?
В принципе да, но если вы его не пропишете то вы просто потеряете часть стектрейса. И если get запрос выдаст ошибку вы не получите точное место откуда она пришла, a место где было обнаружено не выполненный промис.
Что за бред. Функция возвращает промис, ты ее парсишь через await, но в итоге то функция async автоматом твой распарсенный результат обварачивает в дополнительный промис.
А зачем проверку на undefined пихать в блок try catch?
Точно, спасибо за наблюдение
Пожалуйста 👍
Напиши, пожалуйста, как называется твоя тема визуал студио-код?
Bearded Theme Vivid Purple
убирайте await и потом ловите рандомные баги, когда у вас не обрабатывается корректно промис =)
если метод асинхроннный то ты его вызываешь через await.
если вам влом писать букавы, то можете попробовать python например.
с таким успехом можно и от ключевых слов const и let можно отказаться, всё равно переменные будут создаваться и так, какая разница
Так вы возвращаете асинхронную функцию и await перед верхний функции отработает. При чем тут случайные баги?
Я ни где не говорю, что нужно не писать await вообще, но если асинхронная функция возвращает асинхронную функцию, то достаточно await только один раз написать, если мы не хотим внутри ловить ошибку. Вам даже Webstorm подсветит это как замечание.
Если await убрали, по идее нужно и async убрать? Или вы его оставляете только лишь для того, что бы функция возвращала Promise вместо Promise | null?
Верно.
Привет, подскажи какая у тебя тема в vscode стоит?
Bearded Theme Vivid Purple
@@PurpleSchool ✌️
Изначальный код будет плох, если обернуть try/catch на вызывающей стороне, в контроллере например?
Вполне норм, если я правильно понял вопрос
Какая у тебя стоит тема?
Bearded Theme Vivid Purple
А разве промис не возвращает state, если еще не успел отработать?
если не использовать await, да и потому верхний await будет с ним работать верно
Что за редактор?
Visual Studio Code
Что если db.get изначально возвращает промис?Тогда без await сделать будет несколько проблематично
Так он и возвращает, тут как раз и описывается что при том, что он возвращает нас не нужен await, так как мы возвращаем из асинхронной функции.
почему на ютубе все говорят заторможенно?
в сравнении с тикток?
Что за тема?
Bearded Theme Vivid Purple
@@PurpleSchool спасибо 🙏
Зачем в этой функции async вообще
Чтобы использовать await
Null тоже не очень возвращать т.к обязательно каждый раз придется проверять результат на null
Как раз осознанный null лучше пробросать ошибок с разбором какая из ошибок
@@PurpleSchool ну как бэ на get кидаешь ошибку, на find возвращашь null. Нейминг не корректный.
Промисы для меня понятнее, чем async await...
Async await это синтаксис для работы с Promise
@@PurpleSchool мне проще и удобнее использовать then catch finally...
Рекомендую присмотреться к async и await, так как это стандарт на большинстве проектов, как фронта так и бека, который делает код более читабельным
Здесь есть более страшная ошибка. Если мы передадим в getUser 0 то получим null, так как неявный каст
Лучше так не делать...
Что именно не делать?
@@PurpleSchool не убирать await даже когда вы не обрабатываете исключение. Это плохая практика... Экономия копейки, а отладка в случае проблем будет затруднена.
Почему отладка усложниться? Ты так же получишь то же исключение, которые будет поймано выше по стеку.
@@PurpleSchool Ты получишь другой стек вызовов. Из lint это правило убрали, потому что оно в основном вредное. Более того они пишут что сейчас как раз оставлять будут работать быстрее.
@@PurpleSchool тебе уже писали почему, ты как будто не читаешь...
return id ? db.get(id) : null;