Что возвращает async в javascript
Поймут даже дети: простое объяснение async/await и промисов в JavaScript
Привет, Хабр! Представляю вашему вниманию перевод статьи «JavaScript Async/Await and Promises: Explained like you’re five years old» автора Jack Pordi.
Каждый, кто считает себя JavaScript-разработчиком, в какой-то момент должен был столкнуться с callback-функциями, промисами или, с недавних пор, с синтаксисом async/await. Если вы пробыли в игре достаточно долго, вы, вероятно, застали времена, когда вложенные callback-функции были единственным способом достижения асинхронности в JavaScript.
Когда я начал изучать и писать на JavaScript, уже существовало миллиард руководств и туториалов, объясняющих, как добиться асинхронности в JavaScript. Тем не менее, многие из них просто объясняли, как преобразовать callback-функции в промисы или промисы в async/await. Для многих этого, вероятно, более чем достаточно, чтобы они «поладили» с ними и начали использовать их в своем коде.
Однако если вы, как я, действительно хотите понять асинхронное программирование (а не только синтаксис JavaScript!), то, возможно, вы согласитесь со мной, что существует нехватка материалов, объясняющих асинхронное программирование фактически с нуля.
Что значит «асинхронный»?
Как правило, задавая этот вопрос, вы можете услышать что-то из следующего:
Пример из жизни
Представьте, что вы готовите овощной суп. Для хорошей и простой аналогии предположим, что овощной суп состоит только из лука и моркови. Рецепт такого супа может быть следующим:
Теперь давайте перейдем к JavaScript, хорошо?
Итак, придерживаясь того же примера овощного супа, я напишу несколько функций для представления шагов рецепта, описанных выше.
Сначала давайте напишем синхронные функции, которые представляют задачи, не требующие ожидания времени. Это старые добрые функции JavaScript, но обратите внимание, что я описал функции chopCarrots и chopOnions как задачи, требующие активной работы (и времени), позволяя им выполнять некоторые длинные вычисления. Полный код доступен в конце статьи [1].
Перед тем, как перейти к асинхронным функциям, сначала я быстро объясню, как система типов JavaScript обрабатывает асинхронность: в основном все результаты (включая ошибки) асинхронных операций должны быть обернуты в промис(ы).
Чтобы функция возвращала промис, вы можете:
Итак, наши асинхронные функции, представляющие шаги 3–5 приготовления овощного супа, выглядят следующим образом:
Ещё раз, я удалил детали реализации, чтобы на них не отвлекаться, но они опубликованы в конце статьи [1].
Важно знать, что для того, чтобы дождаться результата промиса, чтобы потом можно было с ним что-то делать, вы можете просто использовать ключевое слово await :
Итак, теперь нам просто нужно собрать все это вместе:
Следовательно, мы просто добавляем ключевое слово async в функцию makeSoup :
В контексте функции makeSoup вы можете просто думать о ней как о том, что вы ожидаете, что что-то произойдет (или результат, который в конечном итоге будет возвращен).
Но помните: вы (как и ваш процессор) никогда не захотите просто сидеть и ждать чего-то, в то время как можно потратить свое время на другие дела.
Следовательно, вместо того, чтобы только готовить суп, мы могли бы параллельно готовить что-то еще:
Видите? Синтаксис async/await на самом деле довольно прост в использовании, если вы его понимаете, согласны?
Что насчет явных промисов?
Хорошо, если вы настаиваете, я перейду к использованию явных промисов (прим. перев.: под явными промисами автор подразумевает непосредственно сам синтаксис промисов, а под неявными промисами – синтаксис async/await, т.к. он возвращает промис неявно – не нужно писать return new Promise(…) ). Имейте в виду, что методы async/await основаны на самих промисах и, следовательно, оба варианта полностью совместимы.
Явные промисы, на мой взгляд, находятся между callback-функциями старого стиля и новым сексуальным синтаксисом async/await. В качестве альтернативы, вы также можете думать о сексуальном синтаксисе async/await как о не более чем неявных промисах. В конце концов, конструкция async/await пришла после промисов, которые, в свою очередь, пришли после callback-функций.
Воспользуйтесь нашей машиной времени, чтобы переместиться в «ад обратных вызовов» (callback hell) [4]:
Я не собираюсь лгать, я написал этот пример на лету, когда работал над этой статьей, и это заняло у меня гораздо больше времени, чем я хотел бы признать. Многие из вас, возможно, даже не будут знать, что вообще тут происходит. Мой дорогой друг, разве все эти callback-функции не ужасны? Пусть это будет уроком, чтобы никогда больше не использовать callback-функции.
И, как и обещал, тот же пример с явными промисами:
Как видите, промисы все еще похожи на callback-функции.
Я не буду вдаваться в подробности, но главное:
Заключение
Я надеюсь, что вы получили некоторое представление о промисах и асинхронном программировании из этой статьи или, возможно, хотя бы узнали о хорошем примере из жизни, чтобы объяснить это кому-то еще.
Итак, какой из способов вам использовать: промисы или async/await?
Ответ полностью зависит от вас — и я бы сказал, что совмещать их не так уж и плохо, так как оба подхода полностью совместимы друг с другом.
Тем не менее, лично я нахожусь на 100% в лагере async/await, так как для меня код намного понятнее и лучше отражает истинную многозадачность асинхронного программирования.
Конструкция async/await в JavaScript: сильные стороны, подводные камни и особенности использования
Конструкция async/await появилась в стандарте ES7. Её можно считать замечательным улучшением в сфере асинхронного программирования на JavaScript. Она позволяет писать код, который выглядит как синхронный, но используется для решения асинхронных задач и не блокирует главный поток. Несмотря на то, что async/await — это отличная новая возможность языка, пользоваться ей правильно не так уж и просто. Материал, перевод которого мы публикуем сегодня, посвящён разностороннему исследованию async/await и рассказу о том, как использовать этот механизм правильно и эффективно.
Сильные стороны async/await
Самое важное преимущество, которое получает программист, пользующийся конструкцией async/await, заключается в том, что она даёт возможность писать асинхронный код в стиле, характерном для синхронного кода. Сравним код, написанный с использованием async/await, и код, основанный на промисах.
Привлекательность async/await обеспечивается не только улучшением читабельности кода. Этот механизм, кроме того, пользуется отличной поддержкой браузеров, не требующей каких-либо обходных путей. Так, на сегодняшний день асинхронные функции полностью поддерживают все основные браузеры.
Все основные браузеры поддерживают асинхронные функции (caniuse.com)
Такой уровень поддержки означает, например, что код, использующий async/await, не нужно транспилировать. Кроме того, это облегчает отладку, что, пожалуй, даже более важно, чем отсутствие необходимости в транспиляции.
Отладка асинхронной функции. Отладчик дождётся выполнения await-строки и перейдёт на следующую строку после завершения операции
О неправильном восприятии async/await
В некоторых публикациях конструкцию async/await сравнивают с промисами и говорят о том, что она представляет собой новое поколении эволюции асинхронного программирования на JavaScript. С этим я, при всём уважении к авторам таких публикаций, позволю себе не согласиться. Async/await — это улучшение, но это — не более чем «синтаксический сахар», появление которого не ведёт к полному изменению стиля программирования.
В сущности, асинхронные функции — это промисы. Перед тем, как программист сможет правильно использовать конструкцию async/await, он должен хорошо изучить промисы. Кроме того, в большинстве случаев, работая с асинхронными функциями, нужно использовать и промисы.
Взгляните на функции getBooksByAuthorWithAwait() и getBooksByAuthorWithPromises() из вышеприведённого примера. Обратите внимание на то, что они идентичны не только в плане функционала. У них ещё и совершенно одинаковые интерфейсы.
На самом деле, суть проблемы, о которой мы тут говорим, заключается в неправильном восприятии новой конструкции, когда создаётся обманчивое ощущение того, что синхронную функцию можно конвертировать в асинхронную благодаря простому использованию ключевых слов async и await и ни о чём больше не задумываться.
Подводные камни async/await
Поговорим о наиболее распространённых ошибках, которые можно сделать, пользуясь async/await. В частности — о нерациональном использовании последовательных вызовов асинхронных функций.
Хотя ключевое слово await может сделать код похожим на синхронный, пользуясь им, стоит помнить о том, что код это асинхронный, а значит, надо очень внимательно относиться к последовательным вызовом асинхронных функций.
Этот код, с точки зрения логики, кажется правильным. Однако тут имеется серьёзная проблема. Вот как он работает.
Вот правильный подход к написанию такого кода:
Рассмотрим ещё один пример неправильного использования асинхронных функций. Тут всё ещё хуже, чем в предыдущем примере. Как видите, для того, чтобы асинхронно загрузить список неких элементов, нам надо полагаться на возможности промисов.
Обработка ошибок
▍Конструкция try/catch
Стандартным способом для обработки ошибок при использовании async/await является конструкция try/catch. Я рекомендую пользоваться именно этим подходом. При выполнении await-вызова значение, выдаваемое при отклонении промиса, представляется в виде исключения. Вот пример:
Ошибка, перехваченная в блоке catch — это как раз и есть значение, получающееся при отклонении промиса. После перехвата исключения мы можем применить несколько подходов для работы с ним:
▍Возврат функциями двух значений
Источником вдохновения для следующего способа обработки ошибок в асинхронном коде стал язык Go. Он позволяет асинхронным функциям возвращать и ошибку, и результат. Подробнее об этом можно почитать здесь.
Если в двух словах, то асинхронные функции, при таком подходе, можно использовать так:
Лично мне это не нравится, так как этот способ обработки ошибок привносит в JavaScript стиль программирования на Go, что выглядит неестественно, хотя, в некоторых случаях, это может оказаться весьма полезным.
Для этого подхода характерны две небольших проблемы:
Итоги
Конструкция async/await, которая появилась в ES7, определённо, является улучшением механизмов асинхронного программирования в JavaScript. Она способна облегчить чтение и отладку кода. Однако, для того, чтобы пользоваться async/await правильно, необходимо глубокое понимание промисов, так как async/await — это всего лишь «синтаксический сахар», в основе которого лежат промисы.
Надеемся, этот материал позволил вам ближе познакомиться с async/await, и то, что вы тут узнали, убережёт вас от некоторых распространённых ошибок, возникающих при использовании этой конструкции.
Уважаемые читатели! Пользуетесь ли вы конструкцией async/await в JavaScript? Если да — просим рассказать о том, как вы обрабатываете ошибки в асинхронном коде.
Разбираем Async/Await в JavaScript на примерах
Автор статьи разбирает на примерах Async/Await в JavaScript. В целом, Async/Await — удобный способ написания асинхронного кода. До появления этой возможности подобный код писали с использованием коллбэков и промисов. Автор оригинальной статьи раскрывает преимущества Async/Await, разбирая различные примеры.
Напоминаем: для всех читателей «Хабра» — скидка 10 000 рублей при записи на любой курс Skillbox по промокоду «Хабр».
Skillbox рекомендует: Образовательный онлайн-курс «Java-разработчик».
Callback
Callback представляет собой функцию, вызов которой отложен на неопределенное время. Раньше обратные вызовы использовались в тех участках кода, где результат не мог быть получен сразу.
Вот пример асинхронного чтения файла на Node.js:
Проблемы возникают в тот момент, когда требуется выполнить сразу несколько асинхронных операций. Давайте представим себе вот такой сценарий: выполняется запрос в БД пользователя Arfat, нужно считать его поле profile_img_url и загрузить картинку с сервера someserver.com.
После загрузки конвертируем изображение в иной формат, например из PNG в JPEG. Если конвертация прошла успешно, на почту пользователя отправляется письмо. Далее информация о событии заносится в файл transformations.log с указанием даты.
Стоит обратить внимание на наложенность обратных вызовов и большое количество >) в финальной части кода. Это называется Callback Hell или Pyramid of Doom.
Недостатки такого способа очевидны:
Положительным моментом промисов стало то, что с ними код читается гораздо лучше, причем сверху вниз, а не слева направо. Тем не менее у промисов тоже есть свои проблемы:
Предположим, что есть цикл for, выводящий последовательность чисел от 0 до 10 со случайным интервалом (0–n секунд). Используя промисы, нужно изменить этот цикл таким образом, чтобы числа выводились в последовательности от 0 до 10. Так, если вывод нуля занимает 6 секунд, а единицы — 2 секунды, сначала должен быть выведен ноль, а потом уже начнется отсчет вывода единицы.
Async-функции
Добавление async-функций в ES2017 (ES8) упростило задачу работы с промисами. Отмечу, что async-функции работают «поверх» промисов. Эти функции не представляют собой качественно другие концепции. Async-функции задумывались как альтернатива коду, который использует промисы.
Async/Await дает возможность организовать работу с асинхронным кодом в синхронном стиле.
Таким образом, знание промисов облегчает понимание принципов Async/Await.
В обычной ситуации он состоит из двух ключевых слов: async и await. Первое слово и превращает функцию в асинхронную. В таких функциях разрешается использование await. В любом другом случае использование этой функции вызовет ошибку.
Async вставляется в самом начале объявления функции, а в случае использования стрелочной функции — между знаком «=» и скобками.
Эти функции можно поместить в объект в качестве методов либо же использовать в объявлении класса.
NB! Стоит помнить, что конструкторы класса и геттеры/сеттеры не могут быть асинхронными.
Семантика и правила выполнения
Async-функции, в принципе, похожи на стандартные JS-функции, но есть и исключения.
Так, async-функции всегда возвращают промисы:
В частности, fn возвращает строку hello. Ну а поскольку это асинхронная функция, то значение строки обертывается в промис при помощи конструктора.
Вот альтернативная конструкция без Async:
В этом случае возвращение промиса производится «вручную». Асинхронная функция всегда обертывается в новый промис.
В том случае, если возвращаемое значение — примитив, async-функция выполняет возврат значения, обертывая его в промис. В том случае, если возвращаемое значение и есть объект промиса, его решение возвращается в новом промисе.
Но что произойдет в том случае, если внутри асинхронной функции окажется ошибка?
Если она не будет обработана, foo() вернет промис с реджектом. В этой ситуации вместо Promise.resolve вернется Promise.reject, содержащий ошибку.
Async-функции на выходе всегда дают промис, вне зависимости от того, что возвращается.
Await влияет на выражения. Так, если выражение является промисом, async-функция приостанавливается до момента выполнения промиса. В том случае, если выражение не является промисом, оно конвертируется в промис через Promise.resolve и потом завершается.
А вот описание того, как работает fn-функция.
Решаем задачу
Ну а теперь давайте рассмотрим решение задачи, которая была указана выше.
Вот решение с выводом чисел, здесь есть два варианта.
А вот решение с использованием async-функций.
Необработанные ошибки обертываются в rejected промис. Тем не менее в async-функциях можно использовать конструкцию try/catch для того, чтобы выполнить синхронную обработку ошибок.
canRejectOrReturn() — это асинхронная функция, которая либо удачно выполняется (“perfect number”), либо неудачно завершается с ошибкой (“Sorry, number too big”).
Поскольку в примере выше ожидается выполнение canRejectOrReturn, то собственное неудачное завершение повлечет за собой исполнение блока catch. В результате функция foo завершится либо с undefined (когда в блоке try ничего не возвращается), либо с error caught. В итоге у этой функции не будет неудачного завершения, поскольку try/catch займется обработкой самой функции foo.
Стоит уделить внимание тому, что в примере из foo возвращается canRejectOrReturn. Foo в этом случае завершается либо perfect number, либо возвращается ошибка Error (“Sorry, number too big”). Блок catch никогда не будет исполняться.
Проблема в том, что foo возвращает промис, переданный от canRejectOrReturn. Поэтому решение функции foo становится решением для canRejectOrReturn. В этом случае код будет состоять всего из двух строк:
А вот что будет, если использовать вместе await и return:
В коде выше foo удачно завершится как с perfect number, так и с error caught. Здесь отказов не будет. Но foo завершится с canRejectOrReturn, а не с undefined. Давайте убедимся в этом, убрав строку return await canRejectOrReturn():
Распространенные ошибки и подводные камни
В некоторых случаях использование Async/Await может приводить к ошибкам.
Такое случается достаточно часто — перед промисом забывается ключевое слово await:
В коде, как видно, нет ни await, ни return. Поэтому foo всегда завершается с undefined без задержки в 1 секунду. Но промис будет выполняться. Если же он выдает ошибку или реджект, то в этом случае будет вызываться UnhandledPromiseRejectionWarning.
Async-функции в обратных вызовах
Нам нужны аккаунты ArfatSalman, octocat, norvig. В этом случае выполняем:
Чрезмерно последовательное использование await
В качестве примера возьмем такой код:
Здесь в переменную count помещается число репо, затем это число добавляется в массив counts. Проблема кода в том, что пока с сервера не придут данные первого пользователя, все последующие пользователи будут находиться в режиме ожидания. Таким образом, в единый момент обрабатывается лишь один пользователь.
Promise.all на входе получает массив промисов с возвращением промиса. Последний после завершения всех промисов в массиве или при первом реджекте завершается. Может случиться так, что все они не запустятся одновременно, — для того чтобы обеспечить одновременный запуск, можно использовать p-map.
Заключение
Async-функции становятся все более важными для разработки. Ну а для адаптивного использования async-функций стоит воспользоваться Async Iterators. JavaScript-разработчик должен хорошо разбираться в этом.
Async/Await в javascript. Взгляд со стороны
В последнее время все больше моих друзей, коллег и людей из сообщества говорят про работу с асинхронными функциями и в частности про использование async/await на своих проектах. Я решил разобраться для себя, что это за зверь и стоит ли его использоваться при разработке боевых проектов.
Первое что хочется развеять, это распространенное заблуждение о том, что async/await — это фича ES7.
По моему мнению, использование терминов ES6 и ES7 само по себе не очень верное и может ввести разработчиков в заблуждение. После удачного релиза спецификации ES2015, называемой ES6, у многих людей сложилось ошибочное мнение, что все в нее не вошло и заполифилено через babel — это фичи ES7. Это не так. Вот список того что появится с релизом спецификации ES2016. Как видите он не такой большой и async/await в нем никак не значится.
Я хочу, чтобы мы говорили правильно. И говоря о той, или иной фиче, ссылались на конкретную спецификацию в рамках которой она описана и реализована, а не мифические ES6, ES7 … ESN.
Двигаемся дальше. Так что же такое async/await простыми словами?
Говоря общедоступным языком async/await — это Promise.
Когда вы объявляете функцию как асинхронную, через волшебное слово async, вы говорите, что данная функция возвращает Promise. Каждая вещь которую вы ожидаете внутри этой функции, используя волшебное слово await, то же возвращает Promise.
Это очень важный момент для понимания, как такие функции работают и чего ожидать при работе с ними.
Давайте посмотрим, как же выглядит наш единорог и разберемся как он работает.
Вот простой пример асинхронного Redux экшена для выхода из кабинета:
А теперь идем от общего к частному
После прочтения ряда статей и самостоятельно поигравшись, я составил для себя небольшой бриф, отвечающий на основные вопросы, с небольшими примерами.
Что нужно сделать чтобы начать работу?
Если не использовать никакой системы сборки, то достаточно установить babel и babel-runtime.
В остальных случаях, лучше смотреть настройки исходя их системы сборки и версии babel. Это очень важно, так как настройки в версии babel5 и babel6 сильно различаются.
Как создается асинхронная функция?
Создание асинхронной функции состоит из двух основных частей:
1. Использования слова async перед объявлением функции.
Как мы видим из примера c logout(), это так же работает при использовании стрелочных функций. Еще это работает для функций классов и статичных функций. В последнем случае async пишется после static.
2. В теле самой функции мы должны использовать слово await.
Использование слова await сигнализирует о том, что бы основной код ждал и не возвращал ответ, пока не выполниться какое-то действие. Оно просто обрабатывает Promise для нас и ждет пока он вернет resolve или reject. Таким образом, создается впечатление, что код выполняется синхронно.
* Для работы с await функция должна быть асинхронной и объявлена с помощью ключевого слова async. В противном случае это просто не будет работать.
Как работает await и какую функцию выполняет?
Так как код в синхронном стиле, по этой причине мы можем использовать старый добрый try/catch для решения подобных задач.
Дополнительно хочется акцентировать на этом внимание.
Использование try/catch это единственный способ поймать и обработать ошибку. Если по каким-то причинам вы решите его не использовать или просто забыли, это может привести к отсутствию возможности обработки, а так же потере вовсе.
В какой момент происходит выполнение кода следующего за await?
Код следующий после await, продолжает свое выполнение только тогда когда функция используемая с await вернет resolve или reject.
Что если функция используемая с await не возвращает Promise?
Если функция используемая с await не возвращает Promise, а мы уже знаем, что await его ожидает, то выполнение кода продолжится так как если бы мы не использовали await вообще.
Что если объявить функцию асинхронной, но не использовать await?
В таком случае, на выходе мы получим просто ссылку на Promise функции getRainbow().
Что будет если я напишу несколько функций использующих await подряд?
Такой код будет выполняться последовательно. Сначала отработает getRainbow(), после того как она вернет resolve или reject начнет работать getFood(). Один вызов, один результат.
А если мне нужно одновременно получить результат от нескольких вызовов?
Дополнительно хочу заметить, что конструкция await * arrayOfPromises больше не актуальна и удалена из спецификации. При попытке ее использовать вы по получите сообщение с любовью о том, что лучше использовать Promise.all().
Обновил информацию по конструкции await*. Спасибо xGromMx и degorov.
Что еще хорошо бы знать для успешной работы?
Надо помнить, что если ты начинаешь использовать async/await в своем проекте, нужно быть готовым к тому, что почти весь твой стек должен будет быть асинхронным. А это может добавить не мало проблем и неудобств.
С основными теоретическими аспектами мы разобрались, если что-то осталось непонятным или у Вас есть что дополнить, жду в комментариях.
А для меня пришло время собрать всю информацию воедино, и решить что же мне делать с нашим асинхронным единорогом. Брать с собой в релизное путешествие или оставить дома для своих Pet проектов.
Выводы:
На первый взгляд асинхронные функции вызывают положительные эмоции. Такая няшная штучка делающая твой код синхронно подобным, что делает его более лаконичным и читабельным.
Но это на первый взгляд.
Да, код лаконичен и читабелен. Да, выглядит симпатично. Но как только ты пытаешься писать что-то сложнее чем обычное API или сложные взаимосвязные скрипты, например, очередь задач для работы с базой данных, сразу сталкиваешься с проблемой асинхронного стека.
Почти все вечно зеленые браузеры, из коробки, на 93%-98% поддерживают фичи ES2015 (таблица). Для меня это означает, что начиная новый проект, исходя из требований и стека, я уже задумаюсь об необходимости babel на проекте.
Но, если я решу использовать async/await, я буду обязан использовать babel. И не могу сказать что это добавит красоты в мой код. Ведь официально async/await нет, и не известно будет ли вообще. И это для меня большой минус.
Так же мне очень не нравится тот факт, что если я забыл применить await или просто не удачный копипаст, вместо автоматического вылета на ошибку, я ничего не получу, кроме ссылки на Promise. Это может быть черевато последствиями, особенно когда большой проект с несколькими разработчиками.
Большинство задач с использованием async/await прекрасно решаются с помощью генераторов.
Во-первых, у них и поддержка лучше.
Во-вторых, работа генераторов будет более естественна и предсказуема.
В-третьих сам babel приводит такой код к генераторам при особых настройках пример1, пример2.
Поддержка в NodeJS
Async/await уже экспериментально попал в V8. Это значит что с версии nodejs 7 можно с ним поиграться и поработать прямо из коробки.
Как это сделать:
Итого
Например мне понравилось использовать их в экшенах для Redux. Выглядит все красиво и гармонично.
Этот материал я писал в первую очередь для себя, чтобы разобраться с интересующим меня вопросом. Если данный материал будет еще кому-то полезен, я буду очень рад.
Также, в следующей статье, я бы хотел подробно сравнить разные подходы к реализации асинхронности (колбэки, промисы, генераторы, атомы). Чтобы это было понятно не только гуру, но и людям только начинающим свой путь в javascript.