async-to-generator

bluebird couroutine хз какое отношение к спеке имеет

вот и вся теория: https://tc39.github.io/ecmascript-asyncawait/

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

и не соответствует спеке)

скользкая дорожка

в чем не соответствует?

ну сами промисы не соответствуют - это факт

чем конкретно?

тесты Promise/A+ проходят?

сходу не воспроизведу, edge кейс связанный с чейнингом

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

ок, спасибо. пытаюсь просто понять как babel и ему подобные компилируют подобные вещи в es5

кароче, в ноде ваще никаких проблем от использования bluebird. Только плюсы.

если ты не планируешь переходить на нативный async await никогда, то можно что хочешь делать

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

ну promise.then(fn1); promise.then(fn2)

global.Promise = require('bluebird') и нативные async/await

fn1 -> fn2

я про async await

async await все равно будет нативный промис давать

const promise = Promise.resolve(123); promise.then(console.log.bind(console, 1)); promise.then(console.log.bind(console, 2));

ты про такой код?

самое эффективное под ноду - самое простое. Гугли bluebird.coroutine. yield на await меняешь, вот так оно и выглядит

я для корутин обычно co пользуюсь, нафиг этот блюбед жирноват он как то ))

ну да

я для корутин обычно co пользуюсь, нафиг этот блюбед жирноват он как то ))

я прям тут не раз уже про это спорил) смотри на бенчмарки

global.Promise = require('bluebird') и нативные async/await

а чем нативные промисы плохи?

ну да

и спека говорит что сначала 1, а потом 2 должен выполниться?

а чем нативные промисы плохи?

тормознутые, нет методов для коллекций и прочих плюшек

думаю да)

тормознутые, нет методов для коллекций и прочих плюшек

хм... вроде ж в 6 ноде что то там со скоростью промисов правили... надо бы побенчмаркать как нибудь

я запускал) BB впереди планеты всей)

хм... вроде ж в 6 ноде что то там со скоростью промисов правили... надо бы побенчмаркать как нибудь

стало лучше, но все еще большое отставание

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

он это делает осознанно для того, например, чтобы можно было делать рекурсию на промисах

но это противоречи спеке

увы

мысль в том, что bluebird это просто либа, которая не ставит цель соответствовать спеке

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

а чем нативные промисы плохи?

медленнее, чем блюбирд

сколько таких мелочей - кто знает

и неудобны

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

медленнее, чем блюбирд

хм... я на нативных всегда писал с их появления... надо будет пощупать блюбердные

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

ну да, коллбеки например - технология проверенная временем

// bluebird User.fetchAll().map((user) => { console.log(user); }); // native User.fetchAll().then((users) => { return users.map((user) => { console.log(user); }); }) // bluebird User.fetchAll().map((user) => { console.log(user); }, { concurrency: 1 }); // native // сосницкий

вот пример)

с колбеками код выглядит страшно когда надо штук 40 последовательно выполнить ))

с async await это не нужно

без async await можно взять либу с функциями, работающими с любыми соответствующими стандарту промисами

async/await не избавляют тебя от необходимости выполнять несколько промисов асинхронно, а не последовательно

то есть Promise.props, Promse.map, etc.

для этого есть Promise.all

для этого есть Promise.all

опередил )) только начал писать

у меня нет слов))

ты можешь поверх Promise.all написать Promise.props. Но для Promise.map прямо помучаться прийдется)

то есть Promise.props, Promse.map, etc.

да ну нафиг такое, лучше уж нативный синтаксис плюс async/await или какой нибудь co вместо них...

да ну нафиг такое, лучше уж нативный синтаксис плюс async/await или какой нибудь co вместо них...

еще раз. async/await не избавляют тебя от необходимости работы с коллекциями

да ладно, getPromise().then(arr => Promise.all(arr.map(fn)))

еще раз. async/await не избавляют тебя от необходимости работы с коллекциями

для набора промисов мне всегда Promise.all хватало или ты о чем?

для работы с коллекциями есть for of, forEach, etc

да ладно, getPromise().then(arr => Promise.all(arr.map(fn)))

concurrency?

ну для этого есть хэлпер

мы тут, или в реакт чатике, поднимали этот вопрос. Нет lodash для промисов. Будет - поговорим

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

вообще-то можно и самому написать код, если он нужен

а я перестал lodash примерно год назад пользоваться, все что мне в нем было нужно уже нативно есть

для работы с коллекциями есть for of, forEach, etc

и тебе результат filter хочется дальше в коллекцию промисов смапить. Прыгать вокруг них с Promise.all прям вообще не удобно

или можно написать коротким кусочком кода

или взять блюберд?))

только он не соответствует стандарту. для меня это важно

и потом тестами покрывать это все. А сроки - да кому они нужны?)

и vendor lock-in

так можно взять либу которая расширяет Array

ну покрыть тестами код из 5 строчек не долго...

эм, это абсурд немного)

стек свой опишешь вкратце?

но чет никто не делает так

всмысле - стек?

я тебе 25 venor-lockов перечислю