Async/await: 6 причин забыть о промисах

вы правы, я как-то об этом не подумал.

Async/await: 6 причин забыть о промисах

Так что по рукам или слились? вы берете рантайм от 51-го Firefox и допиливаете туда async/await

А если серьезно, давайте вы мне не будете расказывать – что я должен, а что нет.

>неужели так сложно без bluebird?
ага, а еще без underscore, jquery и еще вагона библиотек, которые в той или иной мере вошли в язык, Browser API

На этом – давайте закончим дискуссию, а то она несколько в другую плоскость перерешла.

Async/await: 6 причин забыть о промисах

оно рекурсивное – вам сейчас расскажут про то что urlов больше чем размер стека. Вы можете это пофиксить извернувшись с .catch – но будет выглядеть уродски

Async/await: 6 причин забыть о промисах

>Что вы везде этот bluebird тащите?
очевидно – нормальная обработка ошибок и приятные фичи

>Можете руками написать асинхронный редьюс?
думаю смогу, но давайте не будем это проверять. Потому что я попрошую взамен гарантий что вы сможете руками добавить в язык async/await

Async/await: 6 причин забыть о промисах

Мы же помним что это js? – тут все сначала стороняя библиотека, а потом идет в язык

Async/await: 6 причин забыть о промисах

>Не надо тащить сюда ворох библиотек
одну и странно слышать это от человека предоставивщего пример на typescript

const Promise = require('bluebird')

const getKey = (initial, urls) =>
  Promise.resolve(urls)
  .reduce(
    key, url => get(url, key),
    initial
  )

Async/await: 6 причин забыть о промисах

да, очепятка – такое бывает с кодом который нельзя протестировать

return getRawData(query)
              .then(rawToJson)

>Но даже при этом всё равно получилось не то же самое, так как «return {}» не тоже самое что «break», и в случае с map перебор продолжится, а в моей случае предпологался выход из цикла

как-то это не логично чуть-чуть(точно не continue)

но ок:

const Promise = require('bluebird')

function gogogo(queryList) {
    return Promise
      .resolve(queryList)
      .map(getType)
      .then((types) =>
        types.find(x => x !=== 1 && x !== 2)
      )
      .map(function(type) { // can be incapsulated in a function but original sample doesn't do that
        if (type === 1) {
            return getJson(query)
        }
        else {
            return getRawData(query)
              .rawToJson(rawData)
        }
      })
      .reduce(Object.assign, {})
}

function doSomething() {
    gogogo(queryList)
      .then(templateGenerator)
      .tap(console.log)
}

doSomething()

>функционал сторонней библиотеки
мы, вроде бы, обсуждаем фичу которая почти везде возможна только с транспилером. Давайте, если на то пошло откажемся от всех библиотек сразу тогда. Представьте как будет интересно – все руками. Заодно и денег будем больше рубить с любого проекта.

Будет как 10 лет назад: «Ищу php-разработчика со своим фреймворком – любителей писать с нуля, просим не беспокоить»

Async/await: 6 причин забыть о промисах

давайте договоримся что вы будете использовать – Pascal или js из 7 осла? Неиспользовать технологии – это луддизм

Кроме того, начните сначала с себя. Ваш комментарий без кода выглядит, мягко говоря, голословно

Async/await: 6 причин забыть о промисах

пока писал это понял – промисы нравятся тем кто предпочитает .map, .filter, .reduce циклам и наоборот async/await – любителям циклов

Хорошо, это или плохо – не знаю, это тема для извечного холивара. Но мне все же кажется, что async/await – позволяет писать в псевдо-синхронной манере игнорируя понимаю когда произойдет асинхронная операция

ну и заодно интересно – есть ли щанс достичь аналогичного поведения с async/await? с concurrency = Infinity или, например, concurrency = 10

Async/await: 6 причин забыть о промисах

Cорри, по понятным причинам не тестал. Попрошу обратить еще внимание на http://bluebirdjs.com/docs/api/promise.map.html#map-option-concurrency – что-то мне подсказывает что оно еще и работать будет быстрее так постарается вызвать все запросы пораньше(как работает async/await в случае цыкла – не уверен, но что-то мне кажется что наш код станет псеводо-синхроным для этого цыкла)

const Promise = require('bluebird')

function gogogo(queryList) {
    return Promise
      .resolve(queryList)
      .map(getType)
      // can be incapsulated in a function but original sample doesn't do that
      .map(function(type) { 
        if (type === 1) {
            return getJson(query)
        }
        else if (type === 2) {
            return getRawData(query)
              .rawToJson(rawData)
        }
        else {
          return {}
        }
      })
      .reduce(Object.assign, {})
}

function doSomething() {
    gogogo(queryList)
      .then(templateGenerator)
      .tap(console.log)
}

doSomething()

Async/await: 6 причин забыть о промисах

ага, вам не показалось странным что в примере с Promise «do something» есть, а в примере с async/await нет?

или вы думаете что «do something» во втором случае будет меньше?

Async/await: 6 причин забыть о промисах

тут важно добавить – что call таки может быть «асинхронным»(например вызвать что-то по сети) и не будет блокировать event-loop(а значит где-то в другом месте что-то может выполнится)

Но сам кусок написан так что call'ы будут выполнятся по очень – если нужно условно одновременно, то нужен Promis.all как mayorvp написал

Async/await: 6 причин забыть о промисах

конечно, но статья называется «Async/await: 6 причин забыть о промисах». Что само по себе уже уже смешно – потому как предлагают забыть о .then и .catch методах промисов.

Async/await: 6 причин забыть о промисах

Если располагать тоже количество «логики» на строчку кода, то выйдет что примеры аналогичны по длине
Например:

const makeRequest = async () => {
  console.log(await getJSON())
  return "done"
}
//против:
const makeRequest = () =>
  getJSON().then(console.log)
    .then(()=> 'done')

Async/await: 6 причин забыть о промисах

у меня сложилось впечатление что вы путаете callback и promise.

>он им и является, потому что стек сохраняется отсюда все плюсы.
вы уверены в своих словах? в чем профит? юзайте все что *sync из стандартной библиотеки – будет вам счастье.

Async/await: 6 причин забыть о промисах

промахнулся комментарием – ответил вам ниже

Async/await: 6 причин забыть о промисах

стоп, кто говорил про callback спагетти? предлагают забыть о промисах

тут предлагают использовать async/await и забыть о промисах делая чуть короче простые примеры. Но ничего не сказано про более сложные кейсы – что делать с типизацией ошибок? как координировать несколько промисов? все это решает bluebird

второе, статья манипулятивна:

const makeRequest = () => {
  return promise1()
    .then(value1 => {
      // do something
      return Promise.all([value1, promise2(value1)])
    })
    .then(([value1, value2]) => {
      // do something          
      return promise3(value1, value2)
    })
}

так выглядит намного короче

const makeRequest = () => promise1()
    .then(value1 => Promise.all([value1, promise2(value1)]))
    .then(([value1, value2]) => promise3(value1, value2))

а с блюбердом совсем так:

const makeRequest = () => promise1()
    .then(value1 => [value1, promise2(value1)])
    .spread((value1, value2) => promise3(value1, value2))

>Движение языка в сторону упрощения
js и так простой, то что с этой «фичей» ассинхронный код начинает выгдлядеть как синхронных – сомнительный плюс.

код ниже не имеет смысла – с тем же успехом можно писать синхроно и не заморачиваться и есть вероятность что даже быстрее будет

const makeRequest = () => {
  return callAPromise()
    .then(() => callAPromise())
    .then(() => callAPromise())
    .then(() => callAPromise())
    .then(() => callAPromise())

Async/await: 6 причин забыть о промисах

Всю статью можно свести к этому предложению
>Однако, например, в C# подобная функциональность есть уже многие годы, и те, кто с этим знакомы, знают, что польза от неё стоит временных неудобств при чтении кода.

Я не луддит мне просто не очевидно зачем менять один синтаксис на другой.

Второе, все приведенные «плюшки» совсем меркнут если использовать bluebird – он очень улучаешт работу с ошибками и дает кучу утилит для координации промисов.

The State of Reactive in JS: практический обзор FRP библиотек

https://habrahabr.ru/post/325320/ вот тут попытался показать пример.

The State of Reactive in JS: практический обзор FRP библиотек

Bacon появился потому что автору было не понятно идея

ИМХО, это очень громкое утверждение – https://baconjs.github.io/api.html#for-rxjs-users, скорее у него было другое виденье вопроса

(матан) и все такое

тут есть три разныех момента:

1. Документация – выглядит как справочник по матану: на тебя вываливают кучу всего и нег говорят зачем тебе это нужно и с чего начинать(e.g.: gettingstarted)
2. Реализация – пояснил в статье свое мнение
3. И про «монады»: не все люди по умолчанию знают что такое «монада», «дуализм», «Monadic Streams», «малый базис». Подобные объяснения отталкивают новичков. По-моему, это одна из причин почему про FRP больше говорят, чем используют