Comments 19
В чем преимущество такого подхода?
Перед чем?
Это не подход. Это объяснение (возможного) внутреннего устройства async/await. А писать код лучше с async/await, естественно.
Кстати, если вы возьмёте код с async/await и прогоните его через транспилятор, чтобы получить код для старого браузера – тоже получите что-то подобное. Довольно неудобно отлаживать будет :-)
Было интересно, но:
Именно это делают транспиляторы вроде Babel при преобразовании async/await в более старые версии JS, где этой функциональности ещё не было. Если вы взглянете на транспилированный код, то сможете провести множество параллелей с нашей реализацией.
Так может пусть и дальше этим занимаются транспиляторы? а мы будем использовать уже всем знакомый async/await? А то в вебе и так зоопарк подходов и разных технологий...
Так статья про "Принцип работы async/await в JavaScript"
в ней предлагается все же окунуться в это дело. Конкретнее - в разделе *Дальнейшие шаги*. Вот поэтому я и предложил так не делать и не пытаться. А если все таки сильно хочется и есть идее лучше, чем сейчас, то тогда сделать пул-реквест в какой-нибудь транспилятор. И если его примут, то я бы с радостью почитал про то, что и как было улучшено.
А что, кто-то предлагал так и писать? 8-O
Близкая аналогия: порой полезно знать, как C компилируется в машинный код, но это не повод писать сразу машинный код.
Видимо все читали ночью как и я )) Я думал это призыв к действию, а не подкапотная работа) С утра перечитал и все стало ясно)
Я хочу оставить эту доработку в качестве упражнения для вас, так как она окажется аналогична реализации успешного пути, и отличаться будут только используемые функции
А вы читали статью ?
Да. Я читал. Типичная статья вида "реализуем сами, чтобы понять, как оно устроено". Много я таких видел.
ЗЫ: Типичный пример таких статей – "напишем собственную реализацию LISP". И там тоже примерно всегда оставляются какие-то упражнения для самостоятельного решения.
Еще раз. Ваше вообщение:
А что, кто-то предлагал так и писать? 8-O
Моя цитата из прочитанной вами статьи:
Я хочу оставить эту доработку в качестве упражнения для вас, так как она окажется аналогична реализации успешного пути, и отличаться будут только используемые функции
и мой ответ в самом первом комментарии:
Так может пусть и дальше этим занимаются транспиляторы? а мы будем использовать уже всем знакомый async/await? ...
Но да ладно, чет я и так слишком "душнила" в этом треде... Сорян, мир вам
Имея приведённый выше код и соответствующий вывод, можем ли мы переписать функцию main() без использования async и await, по-прежнему получив тот же результат?
Не использовать цепочки промисов в main().Очень долго пытался понять, что имел в виду автор такими условиями.
Например:
— В main нельзя использовать цепочки промисов и await, а в других функциях (вызываемых из main) — можно?
— Один вызов then, результат которого не используется, — это уже цепочка? Без then() и await воспользоваться промисом, который возвращает функция wait() не получится.
Какая реализация соответствует духу задачи? (да, я знаю, что это перевод)
Ну вот, например, вариант, написанный за 3 минуты. «Цепочек» в main(), вроде, нет:
async function main() {
console.log('Entry');
return new Promise(resolve => {
wait().then(result => {
console.log(result);
console.log('Exit');
resolve('Return');
});
});
}
Глупый вопрос: откуда взята функция wait()?
Принцип работы async/await в JavaScript