Что плохого в ожидании цепочки обещаний?

Question

Я работаю над приложением Angular 6, и мне сказали, что это анти-паттерн:

await someFunction().then(result => {
    console.log(result);
});

Я понимаю, что бессмысленно ждать цепочку обещаний. Если someFunction () возвращает обещание, вам не нужна цепочка обещаний, если вы ожидаете ее. Вы можете сделать это:

const result = await someFunction();
console.log(result);

Но мне говорят, что ожидание цепочки обещаний может привести к ошибкам или к тому, что в моем коде что-то сломается. Если первый фрагмент кода выше делает то же самое, что и второй фрагмент, то какое это имеет значение, какой используется. Чем опасен первый фрагмент, а вторым - нет?

Answer 1

Если ваш код then возвратил обещание вместо вызова console.log, ваш первый пример будет await, но ваш второй не будет.

Когда вы используете async/await, вы поймаетеваши отказы в try/catch блоках.Ваш код будет менее вложенным и понятным.

Использование then часто приводит к увеличению вложенности и затрудняет чтение кода.

Вы можете await что угодно, независимо от того, возвращает ли онpromise.Иногда это будущее, вызывающее метод, который однажды может стать асинхронным или просто вернуть обещание без объявления асинхронного.

Недостатками являются сложность, производительность и совместимость, и все они бледнеют по сравнению с выигрышами.

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

Answer 2

Мне говорят, что ожидание цепочки обещаний сломает вещи в моем коде.

Не обязательно, ваши два фрагмента кода действительно работают одинаково (до тех пор, пока someFunction() действительно возвращает обещание).

Какое это имеет значение, какой используется. Какие опасности представляет первый фрагмент, а второй - нет?

Труднее понять и поддерживать, смешивать разные стили. Путаница приводит к ошибкам.

Учтите, что вам нужно добавить еще один вызов обещания в месте вызова console.log() или даже условный возврат из функции. Можете ли вы использовать await в обратном вызове, как в другом месте функции, нужно ли return результат обратного вызова then, возможно ли вообще return из внешней функции? Все эти вопросы даже не упоминаются в первом фрагменте. И хотя на них можно легко ответить для вашего игрушечного примера, в реальном коде это может быть не так просто с более сложным и вложенным потоком управления.

Таким образом, вы должны предпочесть более сжатый и чистый. Придерживайтесь await для консистенции , избегайте then в async function s ¹ .

_{1: Конечно, из правила всегда есть исключение. Я бы сказал, что лучше использовать цепочку обещаний для обработки ошибок , в некоторых случаях, когда вы используете catch или второй then обратный вызов.}

Answer 3

Под капотом async / await просто обещает.

То есть, когда у вас есть какой-то код, похожий на:

const result = await myAsyncFunction();   
console.log(result): 

Это то же самое, что и написание:

myAsyncFunction().then(data => {
   const result = data; 
   console.log(result); 
}); 

Причина в том, что вы не должныне смешивать асинхронные / ожидающие и .then цепочки - это потому, что это сбивает с толку.

Лучше просто выбрать один стиль и придерживаться его.

И пока вы выбираете один - вы можете также выбрать async / await - это более понятно.