Комментарии 22
читал это как раз вчера, но полной ясности так и не принесло
Может быть, вам и многим другим непонятно из-за того, что нигде не объясняют самой сути: чтто Observable, по сути, является Iterable, вывернутым наизнанку относительно управления потоком данных: Iterable — это модель pull (сами просим данные), а Observable — push (данные летят в нас).
Мне кажется, после этого видео Эрика Мейера, создателя Rx, не должно остаться вопросов:
https://www.youtube.com/watch?v=sTSQlYX5DU0
Мне кажется, после этого видео Эрика Мейера, создателя Rx, не должно остаться вопросов:
https://www.youtube.com/watch?v=sTSQlYX5DU0
ИМХО не надо. Лучший вариант понять это все — это написать с чистого листа и понять как это работает (как это сделал я давно) Если общественности надо, то я мог постараться рассказать о Rx в статьях, в которых мы бы писали свой Rx с пустого файла и рассмотрели такие темы как lazy evaluation, continuation monads и много чего еще интересного в плане функционального и реактивного программирования. Писать конечно я смогу не часто, но зато обещаю стабильность :D В любом случае, чтобы понять лучше написать и разобрать все самому и понять весь контракт и правила обработки. В Rx5 подход немного поменялся в частности появились новые способы создания новых операторов путем лифтинга ну еще немного изменений, но основной принцип подхода остался.
Если соберетесь, сделайте хорошие и законченные примеры близкие к реальной жизни. Именно этим страдают большинство статей, которые я повстречал.
Ну вот один из таких примеров в котором показано преимущество fp и rp https://jsfiddle.net/xgrommx/a9m50xev/
Простите, преимущество над чем? Я правильно понимаю бизнес-задачу?
Всё?
- Есть N элементов
- При клике на один из них — он становится единственным активным
- При клике с контрол или шифт один элемент добавляется к списку активных
- При клике на активный — все деактивируются
- При клике на активный с контрол или шифт — один деактивируется
Всё?
Ну вот один из таких примеров в котором показано преимущество fp и rp jsfiddle.net/xgrommx/a9m50xev
Вы вот утверждаете, что тут показано преимущество. Но в чём преимущество?
Вот тот же код в императивном стиле: https://jsfiddle.net/0co58hr8/3/
Он, конечно, не так модно выглядит, нету клёвых pipe и кучи смайликов, но он короче, он доступнее для понимания, никаких непонятных библиотек.
А ещё в нем нету странного бага
STR:
Expected:
Active are [1],[2],[3]
Actual:
Active are [1],[3],[4],[5],[6]
- Click on [1]
- Ctrl+Click on [6]
- Ctrl+Click on [6]
- See: Active only [1]
- Shift+Click on [3]
Expected:
Active are [1],[2],[3]
Actual:
Active are [1],[3],[4],[5],[6]
Говорят, что декларативный стиль — о том, что надо сделать, а не как. В вашем примере я не вижу, что. Я вижу какие-то target, pipe, identity. Они как раз и говорят: "у всех элементов возьми таргет, кастани его к jQuery-объекту, измени у всех класс на обратный". Обычная императивщина, просто завернута в кучу функций с непонятными модными названиями.
ps. попробуйте пофиксить вышеназванный баг. Насколько просто в вашем коде это?
НЛО прилетело и опубликовало эту надпись здесь
Код на стримах, конечно, стрёмный, но никакого бага там нет. TheShock реализовал несколько иную логику. Проводник в винде — третюю ([3],[4],[5],[6]). Какая из них правильная — вопрос отдельный.
Правильная же реактивность выглядит как-то так:https://jsbin.com/wazecaruji/edit?js,output
показано преимущество fp и rp
А у вас не «fp и rp», а просто rp, без fp. По сути код очень мало отличается от моего.
Про баг — на самом деле не так важно, как правильно. Больше интересно, если, допустим, это таки баг (ну вот owner считает, что должно быть именно так), то реально ли его пофиксить в том коде?
У меня ооrp. Ключевое отличие от обычного императивного программирования в том, что не надо вручную следить за правильным обновлением зависимых состояний.
НЛО прилетело и опубликовало эту надпись здесь
Очень интересно посмотреть, фиксированное решение. На данный момент это выглядит как легкий подход не работает, и это трудно исправить.
Даже этой статьи хватило чтобы в голове щелкнуло, и появилось впечатление понимания :)
У меня стойкое ощущение, что реактивность крайне схожа с достаточно старым подходом — рассматривать все как поток данных.
В таком виде появляются плюшки в виде Map-Reduce, разделения логики от данных, становится гораздо проще раскидать обработку по разным потокам.
Чем-то похоже на Entity-System (https://habrahabr.ru/post/197920/)
А любителям нырнуть поглубже могу посоветовать эту онлайн-книгу:
www.dataorienteddesign.com/dodmain
У меня стойкое ощущение, что реактивность крайне схожа с достаточно старым подходом — рассматривать все как поток данных.
В таком виде появляются плюшки в виде Map-Reduce, разделения логики от данных, становится гораздо проще раскидать обработку по разным потокам.
Чем-то похоже на Entity-System (https://habrahabr.ru/post/197920/)
А любителям нырнуть поглубже могу посоветовать эту онлайн-книгу:
www.dataorienteddesign.com/dodmain
Спасибо за перевод. Понимания до конца не наступило, но интересно.
Однако, пожалуйста, обращайте внимание на грамотность. Больше всего покоробило практически везде неправильное употребление "-тся"/"-ться" — как будто специально местами поменяли.
Однако, пожалуйста, обращайте внимание на грамотность. Больше всего покоробило практически везде неправильное употребление "-тся"/"-ться" — как будто специально местами поменяли.
Именно благодаря RP подходу у меня фейсбук стал последнее время дико тормозить и лагать?
Катеорический императив лучше.
Для понимания
Для написания
Для обучения новичков
Для входа в разработку
Для поддержки.
Не модный, но вспомните, как модные штуки быстро выходят из моды и потом мы остаемся с этой штукой в виде непонятно работающих библиотек. В некоторых частях удобно использовать, да, но чтобы понять, надо сломать парадигму мышления, а это дается больно.
Для понимания
Для написания
Для обучения новичков
Для входа в разработку
Для поддержки.
Не модный, но вспомните, как модные штуки быстро выходят из моды и потом мы остаемся с этой штукой в виде непонятно работающих библиотек. В некоторых частях удобно использовать, да, но чтобы понять, надо сломать парадигму мышления, а это дается больно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вступление в Реактивное Программирование, которое вы пропустили