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

тесты 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 строчек не долго...

ERROR: S client not available

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

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

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

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

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

ну что ты используешь в работе

библиотеки/фреймворки и тд

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

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

а еще доками. redux 2 месяца доками покрывали. А там 100 строк всего

Не использую почти ничего из библиотек, только клиенты, драйвера, парсеры форматов, etc

> а еще доками. redux 2 месяца доками покрывали. А там 100 строк всего

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

это какой-то бред) дока-то написана уже.

Не использую почти ничего из библиотек, только клиенты, драйвера, парсеры форматов, etc

драйвера к чему?

бд

какой?

разным

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

то есть на sql99 в 2016 году пишешь?

нет

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

а кто не пишет на sql99?

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

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

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

ну я часто используемые мной функции обычно собираю в один модуль и везде его таскаю ))

Может у вас какой-то альтернтивный SQL или на каждый запрос OVER нужен? мне OVER ну понадобился при сложной статистике в остальном ну хз SQL99 вполне актуальный стандарт

тем более что для async await не нужно почти ничего от промисов

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

А это уже вендор локин для девелопера. Кому он будет нужен на собеседовании со своим набором 5строчников?

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

есть xcode, люди ставят AppCode. Есть terminal, люди ставят iterm2. Есть bash, а люди ставят zsh/fish/etc. Я это к чему - стандартное !== хорошее или полностью удовлетворяющее твоим требованиям

ну я часто используемые мной функции обычно собираю в один модуль и везде его таскаю ))

во, я ж говорил

> @NordLuf А это уже вендор локин для девелопера. Кому он будет нужен на собеседовании сосвоим набором 5строчников? нормальным, адекватным людям

другое дело, если нативные промисы тебя полностью устраивают. Они меня в браузере устраивают частично. Но в ноде - это кащунство, мое ИМХО)

а не тем кому нужно чтобы ты знал mongoose прям обязательно

и еще 500 говнолиб с npm