$q, Promises или же task?

Question

[vasIvas]

Во всех языках существуют библиотеки синхронных задач к которым я ужасно привык.
Типа -

first(/** создать объект и передать в него какие-то аргументы*/)
.then(/** получить объект полученный на предыдущем шаге и что-то с ним сделать*/)
.then(/**получить объект полученный на предыдущем шаге и что-то с ним сделать */)...

В js есть что-то подобное в виде Promises и Q, но я не могу понять, являются ли они полным эквивалентом того, о чем говорю я? То есть все примеры которые я когда либо встречал были приведены в контексте асинхронности но я так и не понял, заточены они специально для асинхронности или их можно вообще всегда-всегда использовать?
И если Promises и Q можно использовать в любом "контексте", то что будет лучше в контексте angular?

Если инфы мало, то вот конкретика. Предположим что у меня есть кнопка подписанная на событие click.
По событию я должен - изменить цвет, изменить прозрачность. Если я вынесу вызовы методов, которые будут это делать в хендлер, то получится жесткая связанность и невозможность добавлять что-то на этапе конфигурации. По этому я хочу сделать последовательное выполнение тасков, которые можно будет устанавливать на этапе конфигурации и в хендлере выполнять лишь task.execute().
Подойдет ли для этого Promises и Q?

Answer 1

[Сергей Протько]

промисы, awaitable, таски... все суть одного и тогоже - единоразовые операции. То есть для обработки периодических событий они не подходят. И да, в контексте ангуляра вы можете юзать любую реализацию поддерживающую then, он их сконвертит в свои промисы. В целом же лучше использовать либо нативные промисы, которые уже есть во всяких там хромах, либо $q ангуларовский.

то что вы описываете - event stream. для этого можно взять https://baconjs.github.io/

Comments

[vasIvas]

Я говорил, как мне кажется, говорю о Command pattern.
А Вы сами пользуетесь bacon.js ?

[vasIvas]

vasIvas: у меня вообще есть очень вредная привычка, делать больше чем нужно.
Вот у меня всего две кнопки play и pause, которые видно по очереди. И вместо того чтобы взять и написать if else, я начинаю думать что нужен объект, который будет содержать состояния. Затем нужен объект, который будет хранить объекты-действия, которые нужно связать в объект map и выполнять в объекте "названия не знаю". Ну и естественно ещё нужен объект валидатор этих состояний. И естественно под объект я подразумеваю класс.
Ну естественно сразу цепочку тасков и прочего-прочего. И сразу же сто вопросов, а есть ли это уже в angular, ведь он же по сути архитектурный фраймворк.

[Сергей Протько]

vasIvas: нет, у меня пока небыло таких задач. Ну то есть как, были, но это было довольно давно, тогда я слыхом не слыхивал о реактивном программировании и решение мое хоть и было схожим но намного более некрасиым.

либо я не верно понимаю то что вы хотите сделать, либо Command pattern это несколько не то... оно по смыслу подходит, но не то. Это совершенно другая парадигма программирования, больше связанная с функциональными языками чем с ООП.

> которые видно по очереди

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

ИМХО вы должны попробовать TDD вместо теоритических изысканий, загонов по архитектурам (опять же это все только теория). Максимально простая и быстрая реализация - все что нужно для счастья. А далее рефакторинг. Пытаясь запроектировать систему (довольно простую) вы тратите огромное количество сил на теорию, это может быть клево и весело, но на коммерческих проектах это приведет к большому жирному фэйлу проекта. Я за эволюционный подход, red-greed-refactoring.

[vasIvas]

Сергей Протько: я использую TDD, но дело в том, что я могу сделать и просто и чуть сложнее, но легко поддерживаемое.
Команда, это лишь для красоты кода. Вот например Вы используете .sass вместо css?
Если используете, то представьте, что у .sass взяли и выпилили все его циклы и переменные и остался только Dmitrijs Balcers. И вот Вы стоите перед выбором - использовать один большой файл .css или его аналог .sass у которого каждый класс в отдельном файле и они импортированы в main.sass.. Я выбираю .sass. Так же и команды, они ничего не вносят в код, но делают его более поддерживаемым и читабельным, ведь все "рабочее" Вы пишите в таске. то есть тут как в пулемете Вы его зарядили и начали стрелять пока лента не закончилась. Вот я о чем -

var task:Task = new Task()
.and(new FirstCommand())
.and(new SecondCommand())
.next(new ThirdCommand())
.next(new FourthCommand());
 
task.addEventListener(TaskEvent.TASK_COMPLETE, handleTaskComplete);
task.execute();<code lang="actionscript">



var task:Task = new Task();
 
task.if_(new ConditionProvider())
 .next(new FirstCommand())
 .else_()
 .next(new SecondCommand())
.end();
 
task.addEventListener(TaskEvent.TASK_COMPLETE, handleTaskComplete);
task.execute();
</code>
Вот когда детей учат им говорят, что в хенлерах писать логику нельзя, для этого делают типа postHandler в котором уже вызывают a(), b(). А если потом придется что-то изменить, то не нужно лезть в общую куча, а просто редактируешь нужный метод.
Вот и это так же, только намного сложнее.

[vasIvas]

vasIvas: только сейчас заметил, что вместо "и выпилили все его циклы и переменные и остался только импорт", отобразился какой-то чувак :)

[Сергей Протько]

vasIvas: я использую less и postcss, и postcss по умолчанию не умеет ничего кроме как предоставлять вам доступ к AST CSS.

Что до команд - я знаю о чем вы говорите, но это несколько другая терминология. Я вообще стараюсь не пользоваться ею последнее время, так как:
- меня мало кто понимает из разработчиков, так как далеко не все знают все паттерны наизусть (даже я не знаю)
- кроме них мне нескем об этом поговорить....

Потому я забил, стараюсь придерживаться идей DDD, использую единый язык и поправляю всех кто начинает говорить "ну вот тут я айтемы добавляю в коллекцию сущности" на "ну вот тут я добавляю слайды в презентацию" (как пример).

Что до вашей реализации - хз, в таком виде я бы это не использовал. Вы оперируете терминами ООП, хотя конкретно в этой ситуации (работа с DOM, ивенты) лучше подходят функциональные штуки, каррирование, чейниг, пайплайнинг и т.д.

[vasIvas]

Сергей Протько: ну лично я считаю так - в мини-приложениях можно и "джедайские штучки" делать. Типа все в одну строчку и каррирование вместо ооп. Но как только все начнет разрастаться, то это перерастет в головную боль. Функциональщину и процедурный стиль нужно раз и навсегда уже похоронить. Я убеждаюсь каждый раз в одном - чем дольше отказываешься от ооп, тем сложнее его потом внедрить. Один раз мне нужно было сделать небольшой парсер и я с первых секунд решил что буду писать систему плагинов. Но потом решил что обойдусь по простому и просто сделал все правильно с точки зрения законов ооп, но это было по детски. И потом я зашел в такую точку, что уже не мог поддерживать этот парсер и пришлось все-таки писать систему плагинов. Хотя возмись я за неё с самого начала, время потратил бы в три раза меньше.

Я очень ярый сторонник java архитектуры и мне вот не докажешь что это плохо, я почему-то её в любом языке вижу, даже в том же js. И если пользоваться es6, es7 и говорить что это не настоящие классы, то нужно петицию разработчикам js и обвенить их в слабоумии чтоль.

[Сергей Протько]

vasIvas: функциональщику похоронить собрались? Ну ну, разберитесь лучше с вопросом. Это местами намного более выразительная штука. Особенно для UI. И да, функциональная парадингам не отрицает ООП, их можно комбинировать (посмотрите на scala)

Что до java архитектуры - это конечно круто, но вы не можете контролы нормально сделать у плеера, о чем тогда говорить? Вообще это совершенно разные масштабы, маленькая директивка и java-архитектуры всяких там энтерпрайзов.

Соблюдать solid и хватит (и может быть стараться придерживаться GRASP)

[vasIvas]

Сергей Протько: дело не в том что я не могу сделать кнопку для плеера. Дело в том что я не могу сделать кнопку для плеера рассматривая html и css и js как три разных языка. Я не могу адаптироваться к том, что нет представления. Ведь его роль играет html, но это не представление, это просто бред. Если придерживаться ооп, то кнопки и прочие это все было бы представление. И да,я третий день делаю, но я делаю только из-за того что все в браузерном js делаю впервые. Очень много время уходит не на поиск и чтение информаци, а на переделывание мышления. А безумное css, которое похоже не на работу на плоскости, к которой я привык, а на оригами, меня вообще выбивает из колеи. Я много время потратил на раздумье того, как лучше разбивать sass и jade. В общем я не оправдываюсь и я действительно с трудом удается все это. И я уверен что и бог будет всего лишь божком если на него так посмотреть, а маленький паучок может стать настоящим тираном.

[Сергей Протько]

vasIvas: вы видно никогда не работали с GUI приложениями (WFP, Windows Forms, QT, etc). Там все примерно так же.

html - разметка элементов, семантика
css - стилизация, оформление

Я думаю вам понравится react.js

[vasIvas]

Сергей Протько: вот для примера, я сегодня с двенадцати часов по Москве сижу и думаю, почему у меня с локального файла открытого без сервера в браузере кнопка реагирует на мышь нормально, а в облаке с запущенного сервера нет. Обычная кнопка при наезде на которую в хандлере (пока в хендлере) я устанавливаю ей класс, который плавно увеличивает её альфу. И обратное при отводе. События angular. И вот ведет она себя так, как ей хочется. При чем ведет себя так только в гугле. Подсказали добавлять префиксы -webkit-, но это не помогает.

[Сергей Протько]

vasIvas: юзайте autoprefixer, это вопервых, во вторых какое это имеет отношение к архитектурам и т.д.? в третьих - я без понятия что вы там сделали что у вас проявляются различные поведения в зависимости от того где что загрузилось.