Это цепочка абсолютно синхронных колбэков. Промисами и async/await я пользоваться умею. Суть в том, что у меня есть произвольное число обработчиков, каждый из которых передаёт результат следующему.

синхронных колбеков? Это как?

Хорошо, что промисы отлично полифилятся. Если они окажутся слабым местом, то можно заполифилить блюбёрдом.

синхронный колбек хелл

а так в блюберде куча полезностей, таких как cancel, timeout, delay, finally, promisify, map, try, method

эти часто юзаю

props еще

синхронных колбеков? Это как?

Ок, просто массив синхронных функций.

да, он тоже

Да вообще много всего, когда напишешь все обертки к каждому полезному методу, там размер bluebird и получится

а так в блюберде куча полезностей, таких как cancel, timeout, delay, finally, promisify, map, try, method

+

Ок, просто массив синхронных функций.

[arr].forEach(x => x())

reduce

Ок, просто массив синхронных функций.

Ок, просто массив синхронных функций.

pipe/compose в помощь

еще catch ошибок определенного типа тоже норм

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

[ ... ].reduce( (body, iteration) => iteration(body), reportBody );

pipe/compose в помощь

во это решение, да

Ну в общем случае редьюс, да

в лодаше есть ещё chain но это не про этот кейс )

Ок, просто массив синхронных функций.

Если у тебя просто фактически fn3( fn2( fn1( data ) ) ) то это pipe, а не колбеки

Если у тебя просто фактически fn3( fn2( fn1( data ) ) ) то это pipe, а не колбеки

Вот. Да.

Колбеки вообще вредно синхронными делать.

Вот. Да.

https://github.com/zerobias/ensue ?

Это обёртка над ramda, но именно для такого кейса — чтобы сделать массив функций и просто кинуть их все сразу

Рамду выпилю как руки дойдут до перф. тестов

Вроде в рамде чета штатное было для подобных кейсов, не?

Да, pipe

Не, именно для массива фций любой длины.

Не, sequence там представлен pipe, pipeK, pipeP и такими же compose

Я так полагаю, мне нужно почитать про потоки? =)

Везде нужно передавать каждую функцию в отдельном аргументе

Что жутко бесило)

Для массива функций там есть методы, описываемые общей фразой "примени этот список функций разом к"

Блеа, я точно как-то делал, не используя императивный код, но щас уже и не вспомню.

Ну, короче, я пока обойдусь reduce()

/stat@combot

Главное — получается предсказуемо и, в итоге, тестируемо.

Я зря чтоль тесты писал ?

R.tap(console.log) наше все :))

Эт да))

Эта... А слишком много абстракций — это плохо?

Слишком много чего угодно это плохо.

Отвечает господин Ассемблер

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

Суть в том, что мы используем одну абстракцию над запросами в эластик. Но над ней пришлось внедрить ещё два уровня абстракции. Получается очень круто и удобно снаружи, но мозги заворачиваются сделать обратный анализ.

Первая абстракция — криэйторы фильтров и агрегаций (очень похоже на экшн-криэйторы в Redux), а вторая — чейнинг применения условий.

Ну тут норм вообще, так и надо

Есть опасения, что тем, кто придёт в проект, будет печалька.

fn3(fn2(fn1(data))) vs [ fn1, fn2, fn3 ]

Есть опасения, что тем, кто придёт в проект, будет печалька.

А нет опасений что проект рухнет потому что инвестор разорится раньше, чем фронт протестирует всю рамду и bluebird? ?

Там чейнинг не везде очевидный. Есть, например, чейнинг создания функций, которому на вход нужно посылать инвертированный массив.

А нет опасений что проект рухнет потому что инвестор разорится раньше, чем фронт протестирует всю рамду и bluebird? ?

Нет. =)

Я пока придумал это, голову сломал.

Там чейнинг не везде очевидный. Есть, например, чейнинг создания функций, которому на вход нужно посылать инвертированный массив.

[ R.reverse, Pipe/yourFn ]

Промисифай мы пока ещё не впилили же.

можно руками написать для ноуд апи const pify = fn => (...args) => new Promise((resolve, reject) => { fn(...args, (err, res) => { (err) ? reject(err) : resolve(res); }) });

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

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

Пардон, а какая разница, в каком они API?

Большая

Пардон, а какая разница, в каком они API?

гигантская

Вместо колбеков можно просто писать await readFile

ну или хотя бы readFile(‘name.sss’).then()

Пардон, а какая разница, в каком они API?

раз промисы first class citizen, то апи должно поддерживать этот интерфейс тоже

плюс новичкам проще будет с async/await + promise-based api, чем с коллбеками

ERROR: S client not available

раз промисы first class citizen, то апи должно поддерживать этот интерфейс тоже

но не поддерживает и видимо не будут пилить ((

и скорее всего если сделать ПР то отвергнут

Так они всё ещё не определились добавлять или нет обещания в API?

и скорее всего если сделать ПР то отвергнут

уже есть

обещания, лол

не согласен (с тем, что поддержки промисов не будет в апи). вон, даже браузерные апи переезжают на промисы. взять тот же fetch()

Так они всё ещё не определились добавлять или нет обещания в API?

их добавить слишком сложно

уже есть

не приняли же

не приняли же

верно, но он есть

их добавить слишком сложно

вместо вываливания эксепшена о пропуске коллбека возвращать промис

да сломается немного апи

но в 8 версии могут сделать

их добавить слишком сложно

А в чём именно проблема? Они же могут ломать обратную совместимость. Ну, или можно под спец. флагом менять API на новое.

вместо вываливания эксепшена о пропуске коллбека возвращать промис

если было бы так просто

ты читал тот пр?

Вместо колбеков можно просто писать await readFile

А, вот о чём речь. Туплю. =)

А в чём именно проблема? Они же могут ломать обратную совместимость. Ну, или можно под спец. флагом менять API на новое.

вопрос и к тебе: ты читал тот пр?

пост-мортем дебаг одна из главных проблем

ты читал тот пр?

поделись ссылкой, пожалуйста

вопрос и к тебе: ты читал тот пр?

Нет. Но сейчас пойду искать его.

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

Нет. Но сейчас пойду искать его.

как найдёшь принеси в чат

ну и сегодня ты не успеешь его дочитать

там на пару часов

потом также нужно избежать перф нагрузки для коллбек потребителей

Промисифай нужен для начала

Промисифай нужен для начала

ну он там был в пр

Где?

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

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

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

я же написал «не поддерживают модель "без коллбека возвращать промис"»

вообще не ответил на вопрос

ну ладно