Как стать автором
Обновить

Комментарии 22

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

Мне кажется, после этого видео Эрика Мейера, создателя Rx, не должно остаться вопросов:
https://www.youtube.com/watch?v=sTSQlYX5DU0
Согласимся =)
ИМХО не надо. Лучший вариант понять это все — это написать с чистого листа и понять как это работает (как это сделал я давно) Если общественности надо, то я мог постараться рассказать о Rx в статьях, в которых мы бы писали свой Rx с пустого файла и рассмотрели такие темы как lazy evaluation, continuation monads и много чего еще интересного в плане функционального и реактивного программирования. Писать конечно я смогу не часто, но зато обещаю стабильность :D В любом случае, чтобы понять лучше написать и разобрать все самому и понять весь контракт и правила обработки. В Rx5 подход немного поменялся в частности появились новые способы создания новых операторов путем лифтинга ну еще немного изменений, но основной принцип подхода остался.
Если соберетесь, сделайте хорошие и законченные примеры близкие к реальной жизни. Именно этим страдают большинство статей, которые я повстречал.
Ну вот один из таких примеров в котором показано преимущество fp и rp https://jsfiddle.net/xgrommx/a9m50xev/
Простите, преимущество над чем? Я правильно понимаю бизнес-задачу?

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

Всё?
Edit: шифт ряд выбирает
Ну вот один из таких примеров в котором показано преимущество 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. попробуйте пофиксить вышеназванный баг. Насколько просто в вашем коде это?
НЛО прилетело и опубликовало эту надпись здесь

Код на стримах, конечно, стрёмный, но никакого бага там нет. 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
Спасибо за перевод. Понимания до конца не наступило, но интересно.
Однако, пожалуйста, обращайте внимание на грамотность. Больше всего покоробило практически везде неправильное употребление "-тся"/"-ться" — как будто специально местами поменяли.
Именно благодаря RP подходу у меня фейсбук стал последнее время дико тормозить и лагать?

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

Основная проблема людей, в том что они считают что React это FP,FRP,RP хотя это нифига не так
У меня проблем нет, т.к. я не знаю, что такое React, FP, FRP, PR и прочие LGBT сокращения :D
Катеорический императив лучше.
Для понимания
Для написания
Для обучения новичков
Для входа в разработку
Для поддержки.

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