Я конечно же не имею в виду то, что другие решения отсутствуют. Их куча. Просто хочу понять, о чем ты говоришь и знаком ли ты хоть с одним таким решением.

круто, оказывается есть и преимущества :)

не понял, да, хочу использовать this.state в функциях. Плюс, не хочу использовать много разных правил для разных случаев, поэтому правило одно: в обработчике события this указывает на объект, который сгенерировал событие.

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

ладно, привел. Но по нему непонятно, достаточную функциональность предоставляет твоя функция или нет. Приведешь самую сложную цепочку, с которой сталкивался, с указанием всех данных, которые передаются? Может вообще окажется, что прав B~Vladi

нет, он их по классам распихивает и большая вложенность не возникает

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

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

да тот же async, который ты в статье упомянул, например. Но ни одним таким не пользовался и по сути не написал ни одного приложения на ноде, если ты об этом.

UPD и можно еще добавить, что B~Vladi считает, что поблема не существует. Тут опять же можно столкнуться с задачей, для которой нужно создавать объекты просто чтобы избежать вложенности.

Если он будет указывать на объект, сгенерировавший событие, то нам не будут доступны методы нашего класса, this.state, в частности.Нет, мне просто лень :DМолодец, что уж там. Если есть задача сделать с ООП, то ок. Если нужно сделать какую-то тривиальную фигню, что я привел (те же анимации), то нефиг.Я понимаю, что ты хочешь, чтоб я уселся делать рабочий пример. Спор не стоит пары часов моей работы.То же самое, только с другим синтаксисом. Зато там (в функции waterfall) нет сложных вещей, просто такой-же последовательный вызов функций с коллбеками.

И да, кстати, чем пример с анимациями тебе не нравится? Последовательные анимации вполне себе повседневная задача, в отличии от работы с нодой.

нет, там один объект - цепочка, все доступно

стоит, за это время ты можешь решить, что никому не нужен еще один велосипед :) А потом люди удивляются, что internet is for porn... Хотя, конечно, это только одна сторона правды :)

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

так ты признаешь, что async лучше твоей реализации?

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

Там ведь доступно событие, ты же сам сказал.Можно, только получится лапша-код.Как можно сравнивать целую библиотеку с одной функцией?Какой?

где я это сказал?

а для тебя это такой четкий критерий: лапша/нелапша? И единственный?

Нет

ты меня не правильно понял, хотя я не знаю как это еще можно было понять

var chain = new AsyncChain()
    .setOptions({
        onComplete: function() {
            // this указывает на объект, который сгенерировал событие - chain
        }
    })
    .add(function() {
        // функция выполняется в контексте цепочки
        this.fireEvent('complete')   // this -> chain
    })

хотя дело не в единственный/один-из. Просто требования могут быть разные: кто-то может все действия в цепочки выстраивать, а кто-то наоборот писать все функции с колбеками. И тут не надо забывать, что 20% усилий из ста не приносят заметного результата... а бывает и наоборот, создают проблемы...