Pull to refresh

Comments 22

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

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

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

Всё?
Ну вот один из таких примеров в котором показано преимущество 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. попробуйте пофиксить вышеназванный баг. Насколько просто в вашем коде это?
UFO just landed and posted this here

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


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

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

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

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

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

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

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

А любителям нырнуть поглубже могу посоветовать эту онлайн-книгу:
www.dataorienteddesign.com/dodmain
Спасибо за перевод. Понимания до конца не наступило, но интересно.
Однако, пожалуйста, обращайте внимание на грамотность. Больше всего покоробило практически везде неправильное употребление "-тся"/"-ться" — как будто специально местами поменяли.
Именно благодаря RP подходу у меня фейсбук стал последнее время дико тормозить и лагать?

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

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

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

Articles