Мой синхронный костыль

[FINoM]

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

[x-yuri]

Ну а если мы хотим вызвать цепочку, то получится так: ...add().add().add()() ← видишь?

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

Ты же хочешь использовать всякие вещи, типа this.state в функциях. Получается, что в обработчиках (oncomplete, onfailure) this будет элементом из события (в случае прямого запуска это будет window), а в функциях из цепочки this будет являться объектом chain?

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

Кто определяет как должно быть?

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

Блин, привел же.

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

Значит для него вложенные вызовы — это нормально.

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

Описана задача сделать этот код более плоским.

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

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

Каких именно? Приведи хотя-бы одно.

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

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

[FINoM]

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

Если он будет указывать на объект, сгенерировавший событие, то нам не будут доступны методы нашего класса, this.state, в частности.

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

Нет, мне просто лень

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

Молодец, что уж там. Если есть задача сделать с ООП, то ок. Если нужно сделать какую-то тривиальную фигню, что я привел (те же анимации), то нефиг.

Ты специально не хочешь понимать о чем я говорю?

Я понимаю, что ты хочешь, чтоб я уселся делать рабочий пример. Спор не стоит пары часов моей работы.

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

То же самое, только с другим синтаксисом. Зато там (в функции waterfall) нет сложных вещей, просто такой-же последовательный вызов функций с коллбеками.

[FINoM]

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

[x-yuri]

Если он будет указывать на объект, сгенерировавший событие, то нам не будут доступны методы нашего класса, this.state, в частности.

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

Нет, мне просто лень

Я понимаю, что ты хочешь, чтоб я уселся делать рабочий пример. Спор не стоит пары часов моей работы.

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

Молодец, что уж там. Если есть задача сделать с ООП, то ок. Если нужно сделать какую-то тривиальную фигню, что я привел (те же анимации), то нефиг.

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

То же самое, только с другим синтаксисом. Зато там (в функции waterfall) нет сложных вещей, просто такой-же последовательный вызов функций с коллбеками.

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

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

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

[FINoM]

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

Там ведь доступно событие, ты же сам сказал.

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

Можно, только получится лапша-код.

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

Как можно сравнивать целую библиотеку с одной функцией?

А по поводу анимаций, у библиотек обычно свой интерфейс для этого имеется.

Какой?

[x-yuri]

Там ведь доступно событие, ты же сам сказал.

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

Можно, только получится лапша-код.

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

[FINoM]

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

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

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

Нет

[x-yuri]

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

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

Нет

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