Сравнение core.async и функционального реактивного программирования (+Rx)

Я думаю, что основная проблема заключается в том, что ваше предположение о решаемой проблеме не совсем так, поскольку ни один из них не решает «проблему» асинхронности.

Абстракции

FRP основная идея заключается в распространении изменений, подумайте о том, чтобы выполнить то же самое, что делает Excel, где вы определяете ячейки, зависящие друг от друга в каскаде, и когда одна ячейка изменяется, все зависимые ячейки в каскаде пересчитано.

core.async основная идея заключается в декомпозиции систем, представьте, что задачи разделяются с помощью queue в середине разных процессов, в core.async случае вместо очередей у ​​вас есть каналы, но вы поняли идею.

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

О завершении потока управления

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

Хотя существуют различные механизмы для очистки событий/обратных вызовов (FRP, Rx/Observables), они не меняют своей фундаментальной природы, заключающейся в том, что при событии запускается произвольное количество другого кода, возможно, в том же потоке, что приводит к предостережения, такие как «не делайте слишком много работы в своем обработчике», и такие фразы, как «ад обратных вызовов».

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

Это то, что решает core.async, поскольку введение очереди/канала посередине помогает лучше разделить задачи.

Реализация

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

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

Последние мысли

Даже если Rx можно использовать для моделирования любого потока данных, он чаще используется для рендеринга пользовательского интерфейса в стиле Excel, чтобы упростить обновление представления при изменении модели.

С другой стороны, Core.Async можно использовать для моделирования разделения проблем, когда любые две подсистемы взаимодействуют друг с другом (тот же сценарий использования, что и очереди), используя его в цепочке рендеринга пользовательского интерфейса, основная идея заключается в разделении:

• Генерация и обработка событий на стороне сервера
• Как это событие влияет на вашу модель

Таким образом, вы можете иметь core.async и FRP вместе, поскольку core.async будет разделять задачи, а FRP будет определять ваш каскадный поток данных после обновления вашей модели.

По крайней мере, одно из основных принципиальных отличий, и, как мне кажется, то, чем Rich ment by «[FRP] завершает обмен сообщениями с потоком управления», заключается в следующем.

Обратные вызовы — это код, который выполняется. И это выполнение должно произойти в каком-то потоке в какой-то момент времени. Часто это время, когда происходит событие, а поток — это поток, который замечает/производит событие. Если вместо этого производитель помещает сообщение в канал, вы можете использовать это сообщение, когда хотите, в любом потоке, который хотите. Таким образом, обратные вызовы, которые по сути являются формой связи, дополняют связь с потоком управления, диктуя, когда и где выполняется код обратного вызова. Если вам по какой-либо причине приходится использовать обратные вызовы, просто используйте их, чтобы поместить сообщение в очередь/канал, и вы снова в деле.

Поскольку core.async менее сложен, ему следует отдавать предпочтение, если нет веской причины использовать альтернативы.

Clojure core.async — это порт блоков go из Перейти на язык. Фундаментальной концепцией являются каналы, представляющие асинхронную связь между потоками.

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

В отличие от FRP, который по-прежнему основан на обратных вызовах и завершает обмен сообщениями с потоком управления. core.async полностью исключает обратные вызовы из вашего кода и отделяет поток управления от передачи сообщений. Кроме того, в FRP канал не является объектом первого класса (т. е. вы не можете отправить канал FRP в качестве значения на канале FRP).

РЕДАКТИРОВАТЬ:

Чтобы ответить на ваши вопросы:

1. Да, во многих случаях обратные вызовы могут быть устранены, например, с помощью логики повторных попыток, DifferentUntilChanged и многих других вещей, таких как:

   var obs = getJSON('story.json').retry(3);

   var obs = Rx.Observable.fromEvent(document, 'keyup').distinctUntilChanged();

2. Я не уверен, к чему это относится, усложняя управление потоком.

3. Да, вы можете передавать объект так же, как и канал, как в случае с объектом ниже.

Например, здесь вы можете вести себя как канал, используя RxJS с ReplaySubject:

var channel = new Rx.ReplaySubject();

// Send three observables down the chain to subscribe to
channel.onNext(Rx.Observable.timer(0, 250).map(function () { return 1; }));
channel.onNext(Rx.Observable.timer(0, 1000).map(function () { return 2; }));
channel.onNext(Rx.Observable.timer(0, 1500).map(function () { return 3; }));

// Now pass the channel around anywhere!
processChannel(channel);

Чтобы сделать его немного более конкретным, сравните код из сообщения Дэвида Нолена здесь с примером RxJS FRP здесь

Здесь есть сообщение, в котором FRP сравнивается с CSP на ограниченном наборе примеров (которые, однако, предназначены для демонстрации преимуществ CSP), с выводом в конце: http://potetm.github.io/2014/01/07/frp.html