Вступление в Реактивное Программирование, которое вы пропустили

[SaturnTeam]

читал это как раз вчера, но полной ясности так и не принесло

[burjui]

Может быть, вам и многим другим непонятно из-за того, что нигде не объясняют самой сути: чтто Observable, по сути, является Iterable, вывернутым наизнанку относительно управления потоком данных: Iterable — это модель pull (сами просим данные), а Observable — push (данные летят в нас).

Мне кажется, после этого видео Эрика Мейера, создателя Rx, не должно остаться вопросов:
https://www.youtube.com/watch?v=sTSQlYX5DU0

[xGromMx]

Согласимся =)

[xGromMx]

ИМХО не надо. Лучший вариант понять это все — это написать с чистого листа и понять как это работает (как это сделал я давно) Если общественности надо, то я мог постараться рассказать о Rx в статьях, в которых мы бы писали свой Rx с пустого файла и рассмотрели такие темы как lazy evaluation, continuation monads и много чего еще интересного в плане функционального и реактивного программирования. Писать конечно я смогу не часто, но зато обещаю стабильность :D В любом случае, чтобы понять лучше написать и разобрать все самому и понять весь контракт и правила обработки. В Rx5 подход немного поменялся в частности появились новые способы создания новых операторов путем лифтинга ну еще немного изменений, но основной принцип подхода остался.

[SaturnTeam]

Если соберетесь, сделайте хорошие и законченные примеры близкие к реальной жизни. Именно этим страдают большинство статей, которые я повстречал.

[xGromMx]

Ну вот один из таких примеров в котором показано преимущество fp и rp https://jsfiddle.net/xgrommx/a9m50xev/

[TheShock]

Простите, преимущество над чем? Я правильно понимаю бизнес-задачу?

1. Есть N элементов
2. При клике на один из них — он становится единственным активным
3. При клике с контрол или шифт один элемент добавляется к списку активных
4. При клике на активный — все деактивируются
5. При клике на активный с контрол или шифт — один деактивируется
   

Всё?

[TheShock]

Edit: шифт ряд выбирает

[TheShock]

Ну вот один из таких примеров в котором показано преимущество fp и rp jsfiddle.net/xgrommx/a9m50xev

Вы вот утверждаете, что тут показано преимущество. Но в чём преимущество?
Вот тот же код в императивном стиле: https://jsfiddle.net/0co58hr8/3/
Он, конечно, не так модно выглядит, нету клёвых pipe и кучи смайликов, но он короче, он доступнее для понимания, никаких непонятных библиотек.

А ещё в нем нету странного бага

STR:

1. Click on [1]
2. Ctrl+Click on [6]
3. Ctrl+Click on [6]
4. See: Active only [1]
5. Shift+Click on [3]

Expected:
Active are [1],[2],[3]

Actual:
Active are [1],[3],[4],[5],[6]

Говорят, что декларативный стиль — о том, что надо сделать, а не как. В вашем примере я не вижу, что. Я вижу какие-то target, pipe, identity. Они как раз и говорят: "у всех элементов возьми таргет, кастани его к jQuery-объекту, измени у всех класс на обратный". Обычная императивщина, просто завернута в кучу функций с непонятными модными названиями.

ps. попробуйте пофиксить вышеназванный баг. Насколько просто в вашем коде это?

[vintage]

Код на стримах, конечно, стрёмный, но никакого бага там нет. TheShock реализовал несколько иную логику. Проводник в винде — третюю ([3],[4],[5],[6]). Какая из них правильная — вопрос отдельный.

Правильная же реактивность выглядит как-то так:https://jsbin.com/wazecaruji/edit?js,output

[TheShock]

показано преимущество fp и rp

А у вас не «fp и rp», а просто rp, без fp. По сути код очень мало отличается от моего.

Про баг — на самом деле не так важно, как правильно. Больше интересно, если, допустим, это таки баг (ну вот owner считает, что должно быть именно так), то реально ли его пофиксить в том коде?

[vintage]

У меня ооrp. Ключевое отличие от обычного императивного программирования в том, что не надо вручную следить за правильным обновлением зависимых состояний.

[yaroslavya]

Очень интересно посмотреть, фиксированное решение. На данный момент это выглядит как легкий подход не работает, и это трудно исправить.

[technont64]

Даже этой статьи хватило чтобы в голове щелкнуло, и появилось впечатление понимания :)
У меня стойкое ощущение, что реактивность крайне схожа с достаточно старым подходом — рассматривать все как поток данных.
В таком виде появляются плюшки в виде Map-Reduce, разделения логики от данных, становится гораздо проще раскидать обработку по разным потокам.

Чем-то похоже на Entity-System (https://habrahabr.ru/post/197920/)

А любителям нырнуть поглубже могу посоветовать эту онлайн-книгу:
www.dataorienteddesign.com/dodmain

[baldr]

Спасибо за перевод. Понимания до конца не наступило, но интересно.
Однако, пожалуйста, обращайте внимание на грамотность. Больше всего покоробило практически везде неправильное употребление "-тся"/"-ться" — как будто специально местами поменяли.

[TheRabbitFlash]

Именно благодаря RP подходу у меня фейсбук стал последнее время дико тормозить и лагать?

[vintage]

Да нет, там и рп-то не используется.

[xGromMx]

Основная проблема людей, в том что они считают что React это FP,FRP,RP хотя это нифига не так

[TheRabbitFlash]

У меня проблем нет, т.к. я не знаю, что такое React, FP, FRP, PR и прочие LGBT сокращения :D

[AcidLynx]

Катеорический императив лучше.
Для понимания
Для написания
Для обучения новичков
Для входа в разработку
Для поддержки.

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