В чем разница между обещаниями JavaScript и асинхронным ожиданием?

Я уже использую функции ECMAScript 6 и ECMAScript 7 (благодаря Babel) в своих приложениях - как мобильных, так и веб-.

Первым шагом, очевидно, был уровень ECMAScript 6. Я выучил много асинхронных шаблонов, обещаний (которые действительно многообещающие), генераторов (не знаю, почему символ *) и т.д. Из этих обещаний вполне подходили моей цели. И я довольно часто их использую в своих приложениях.

Вот пример/псевдокод того, как я реализовал базовый promise-

var myPromise = new Promise(
    function (resolve,reject) {
      var x = MyDataStore(myObj);
      resolve(x);
    });

myPromise.then(
  function (x) {
    init(x);
});

Со временем я наткнулся на функции ECMAScript 7, среди которых были ключевые слова/функции ASYNC и AWAIT. Они вместе делают великие чудеса. Я начал заменять некоторые из моих обещаний async & await. Они, кажется, добавляют большую ценность стилю программирования.

Опять же, вот псевдокод того, как выглядит моя асинхронная функция ожидания like-

async function myAsyncFunction (myObj) {
    var x = new MyDataStore(myObj);
    return await x.init();
}
var returnVal = await myAsyncFunction(obj);

Если оставить в стороне ошибки синтаксиса (если они есть), то они оба делают одно и то же - это то, что я чувствую. Я почти смог заменить большинство своих обещаний асинхронными, ждет.

Почему требуется асинхронное ожидание, когда обещания выполняют аналогичную работу?

Асинк, ждут, решить большую проблему? Или это было просто другое решение для обратного вызова ада?

Как я уже говорил ранее, я могу использовать обещания и асинхронные, ожидаю решения той же проблемы. Есть ли что-то конкретное, что async await решено?

Дополнительные примечания:

Я широко использую async, ждет и обещает в своих проектах React и модулях Node.js. Реакция особенно была ранней пташкой и переняла много функций ECMAScript 6 и ECMAScript 7.

Ответ 1

Почему асинхронный запрос выполняется, когда Promises выполняет аналогичную работу? Асинхронно, ожидайте решения более серьезной проблемы?

async/await просто дает вам синхронное ощущение асинхронного кода. Это очень элегантная форма синтаксического сахара.

Для простых запросов и обработки данных Promises может быть прост, но если вы столкнетесь с сценариями, где сложная манипуляция данными и что-то не так, легче понять, что происходит, если код просто выглядит так, как если бы он был синхронным по-другому, синтаксис сам по себе является формой "случайной сложности", которая может async/await обойти).

Если вам интересно узнать, вы можете использовать библиотеку, например co (наряду с генераторами), чтобы дать такое же ощущение, Такие вещи были разработаны для решения проблемы, которую async/await в конечном итоге решает (изначально).

Ответ 2

Async/Await обеспечивает более приятный синтаксис в более сложных сценариях. В частности, все, что связано с циклами или некоторыми другими конструкциями типа try/catch.

Например:

while (!value) {
  const intermediate = await operation1();
  value = await operation2(intermediate);
}

Этот пример будет значительно более сложным, используя Promises.

Ответ 3

Мой вопрос здесь: почему асинхронное ожидание необходимо, когда Promises выполняет аналогичную работу? Асинк, ждут, решить большую проблему? или это было просто другое решение для обратного вызова ада? Как я уже говорил ранее, я могу использовать Promises и Async, Await для решения той же проблемы. Есть ли что-то конкретное, что Async Await решил?

Прежде всего вы должны понять, что синтаксис async/await - это просто синтаксический сахар, который предназначен для увеличения обещаний. Фактически возвращаемое значение async функции является обещанием. Синтаксис async/await дает нам возможность писать асинхронно синхронно. Вот пример:

Обещание цепочки:

function logFetch(url) {
  return fetch(url)
    .then(response => response.text())
    .then(text => {
      console.log(text);
    }).catch(err => {
      console.error('fetch failed', err);
    });
}

Async функция:

async function logFetch(url) {
  try {
    const response = await fetch(url);
    console.log(await response.text());
  }
  catch (err) {
    console.log('fetch failed', err);
  }
}

В приведенном выше примере await ожидает разрешения или отклонения обещания (fetch(url)). Если обещание разрешено, значение сохраняется в переменной response, если обещание отклонено, оно выдаст ошибку и, таким образом, войдет в блок catch.

Мы уже видим, что использование async/await может быть более читабельным, чем цепочка обещаний. Это особенно верно, когда количество обещаний, которые мы используем, увеличивается. Обе цепочки Promise и async/await решают проблему ада обратного вызова, и какой метод вы выбираете, зависит от личных предпочтений.

Ответ 4

Async/await может помочь сделать ваш код чище и более читабельным в тех случаях, когда вам нужен сложный поток управления. Это также производит более дружественный к отладке код. И позволяет обрабатывать как синхронные, так и асинхронные ошибки с помощью просто try/catch.

Я недавно написал этот пост, демонстрирующий преимущества async/await по сравнению с обещаниями в некоторых типичных случаях использования с примерами кода https://hackernoon.com/6-reasons-why-javascripts-async-await-blows-promises-away-tutorial- c7ec10518dd9

Ответ 5

Полное сравнение с плюсами и минусами.

Обычный JavaScript

Pros

Не требует дополнительных библиотек или технологий

Оптимальная производительность

Обеспечивает лучший уровень совместимости с сторонними библиотеками.

Позволяет создавать специальные и более сложные алгоритмы

Против

Может потребоваться дополнительный код и относительно сложные алгоритмы

Async (библиотека)

Pros

Упрощает наиболее распространенные шаблоны управляющих потоков

Является еще решением на основе обратного вызова

Хорошая производительность

Против

Вводит внешнюю зависимость

Возможно, недостаточно для расширенных потоков

Promises

Pros

Очень упрощает наиболее распространенные шаблоны управляющих потоков

Надежная обработка ошибок

Часть спецификации ES2015

Гарантирует отложенный вызов onFulfilled и onRejected

Против

Требуется пролонгировать API на основе обратного вызова.

Представляет небольшой хит производительности

Генераторы

Pros

Делает неблокирующий API похожим на блокирующий

Упрощает обработку ошибок.

Часть спецификаций ES2015

Против

Требуется дополнительная библиотека управляющего потока

По-прежнему требуются обратные вызовы или promises для реализации не последовательных потоков

Требуется thunkify или promisify API-интерфейсы, основанные на nenerenerator.

Async ждет

Pros

Делает неблокирующий API похожим на блокировку

Чистый и интуитивно понятный синтаксис

Против

Требуется Babel или другие транспилеры и некоторая конфигурация, которые будут использоваться сегодня.

Ответ 6

оба способа обработки асинхронного кода. Но есть разница между исполнением каждого. Вот рабочее исполнение -

обещание

Объект Promise представляет возможное завершение (или сбой) асинхронной операции и ее результирующее значение. Это прокси для значения, которое не обязательно известно во время его создания, и оно представляет будущий результат асинхронной операции.

Вызывающий код может подождать, пока это обещание будет выполнено, прежде чем выполнить следующий шаг. Для этого в обещании есть метод then, который принимает функцию, которая будет вызываться при выполнении обещания.

Асинхронный /Await

Когда async функция вызывается, она возвращает Promise. Когда async функция возвращает значение, Promise будет разрешено с возвращенным значением. Когда async функция генерирует исключение или какое-либо значение, Обещание будет отклонено с брошенным значением.

Асинхронная функция может содержать выражение await, которое приостанавливает выполнение асинхронной функции и ожидает переданного разрешения Promise, а затем возобновляет выполнение асинхронной функции и возвращает разрешенное значение.

плюсы асинхронного/ожидания над обещанием

Async/await создан для того, чтобы придать чистый синтаксис семантике продолжения асинхронных операций.
Это избегает ада обратного вызова/обещания.