core.async 및 Functional Reactive Programming (+ Rx) 비교

core.async 및 Functional Reactive Programming (+ Rx) 비교

---

Clojure의 core.async 를 일반적으로 소위 Reactive Extensions (Rx) 및 FRP 와 비교할 때 약간 혼란스러운 것 같습니다 . 그들은 비동기-시간 성의 유사한 문제를 다루는 것처럼 보이므로 주요 차이점은 무엇이며 어떤 경우에 다른 하나가 선호되는지 궁금합니다. 누군가 설명해 주시겠습니까?

편집 : 더 심층적 인 답변을 장려하기 위해 질문을 더 구체적으로 만들고 싶습니다.

1. Core.async를 사용하면 동기식 코드를 작성할 수 있습니다. 그러나 내가 이해하기 때문에 FRP는 한 수준의 중첩 콜백 만 필요합니다 (논리를 처리하는 모든 함수는 FRP API에 인수로 전달됨). 이것은 두 접근법 모두 콜백 피라미드를 불필요하게 만드는 것 같습니다 . JS에서 function() {...}여러 번 작성해야하는 것은 사실 이지만 주요 문제인 중첩 콜백도 FRP에서도 사라졌습니다. 내가 맞아?

2. " FRP 는 제어의 흐름으로 메시지의 통신을 구성합니다."(누군가) 좀 더 구체적인 설명을 해주시겠습니까?

3. 채널을 전달하는 것과 같은 방식으로 FRP의 관찰 가능한 끝점을 전달할 수 없습니까?

일반적으로 나는 두 가지 접근 방식이 역사적으로 어디에서 왔는지 이해하고 두 가지 모두에서 몇 가지 자습서를 시도했습니다. 그러나 나는 차이의 불명확함에 의해 "마비 된"것 같다. 이 중 하나에서는 작성하기 어렵고 다른 하나는 사용하기 쉬운 코드의 예가 있습니까? 그 구조적 이유는 무엇입니까?

---

나는 주요 문제는 그들 중 누구도 비동기 성 "문제"를 다루고 있지 않기 때문에 해결 된 문제에 대한 당신의 가정이 그다지 그렇지 않다는 것이라고 생각합니다 .

추상화

FRP주요 아이디어는 변경 사항 전파입니다. Excel에서 수행하는 것과 동일한 작업을 수행하는 것에 대해 생각해보십시오. 여기서는 계단식 으로 서로 종속 된 셀을 정의 하고 하나의 셀이 변경되면 계단식의 모든 종속 셀이 다시 계산됩니다.

core.async주요 아이디어는 시스템 분해 입니다. 대기열 대신 채널이 있지만 아이디어를 얻은 경우를 대비 queue하여 서로 다른 프로세스의 중간에있는 문제를 분리 core.async하는 것으로 생각하십시오.

따라서 피라미드 형 코드를 제거하는 것은 두 기술의 목표가 아니며 서로 다른 추상화 계층에서 작동합니다.

제어 흐름 준수 정보

통신 및 흐름 제어를 구성하는 아이디어 는 원래의 핵심 비동기 게시물 에서 가져 왔습니다 .

이벤트 / 콜백 (FRP, Rx / Observables)을 더 깨끗하게 만드는 다양한 메커니즘이 있지만 기본 특성을 변경하지 않습니다. 즉, 이벤트시 동일한 스레드에서 임의의 양의 다른 코드가 실행되어 "처리기에서 너무 많은 작업을하지 마십시오"와 같은 훈계 및 "콜백 지옥"과 같은 문구.

다시 말해, 이벤트 핸들러 내부에 비즈니스 도메인 코드 가있는 경우 X 이벤트 처리 를 X가 발생할 때 수행 할 작업으로 구성한 것 입니다.

어느 무엇 core.async태클을하는 도입 이후 큐 / 채널을 중간에 우려의 더 나은 분리하는 데 도움이됩니다.

이행

콜백 및 관찰 가능한 엔드 포인트를 매개 변수로 전달하는 것과 관련된 모든 질문은 구현 질문 일 뿐이며 실제로 Rx구현 및 API 에 따라 다릅니다 .

React 재사용 가능한 구성 요소 를 살펴보면 실제로 콜백 지옥이별로 보이지 않으며 Observable을 전달하는 아이디어를 얻을 수 있습니다.

마지막 생각들

Rx데이터 흐름을 모델링하는 데 사용할 수 있더라도 모델이 변경 될 때 뷰를 업데이트하는 방법을 단순화하기 위해 Excel에서 UI 렌더링에 더 일반적으로 사용 됩니다.

반면에 Core.Async두 하위 시스템이 서로 통신 할 때 (큐와 동일한 사용 시나리오) 관심사 분리를 모델링하는 데 사용할 수 있으며, UI 렌더링 체인에서 사용하는 주요 아이디어는 분리하는 것입니다.

• 서버 측 이벤트 생성 및 처리
• 이벤트가 모델에 미치는 영향

당신은 할 수 있도록 core.async하고 FRP있기 때문에, 함께 core.async문제를 분리하며, FRP모델이 업데이트되면 당신의 계단식 데이터 흐름을 정의합니다.

---

주된 주요 차이점 중 적어도 하나는 "[FRP]의 Richment가 제어 흐름과 함께 메시지의 통신을 보완한다"고 생각합니다.

콜백은 실행되는 코드입니다. 그리고 그 실행은 어떤 시점에서 어떤 스레드에서 일어나야합니다. 종종 시간은 이벤트가 발생하는 시점이고 스레드는 이벤트를 감지 / 생성하는 스레드입니다. 제작자가 대신 채널에 메시지를 넣으면 원하는 스레드에서 원하는 시간에 메시지를 자유롭게 사용할 수 있습니다. 따라서 본질적으로 통신의 한 형태 인 콜백은 콜백 코드가 실행되는시기와 위치를 지정하여 제어 흐름과 통신을 보완합니다. 어떤 이유로 든 콜백을 사용해야하는 경우, 콜백을 사용하여 대기열 / 채널에 메시지를 넣기 만하면 다시 정상으로 돌아옵니다.

core.async는 덜 복잡하기 때문에 대안을 사용할 합당한 이유가없는 한 선호해야합니다.

---

Clojure core.async는 Go 언어의 go 블록 포트입니다 . 기본 개념은 스레드 간의 비동기 통신을 나타내는 채널입니다.

목표는 입력을 얻기 위해 채널에 액세스하는 정상적인 순차 코드 블록을 작성할 수 있도록하는 것이며, 이는 CSP 변환을 수행하는 상태 머신으로 원활하게 변환됩니다 .

여전히 근본적으로 콜백에 관한 FRP와 대조적이며 제어 흐름으로 메시지 통신을 구성합니다. core.async는 코드에서 콜백을 완전히 제거하고 제어 흐름을 메시지 전송과 분리합니다. 또한 FRP에서 채널은 1 급 객체가 아닙니다 (즉, FRP 채널의 값으로 FRP 채널을 보낼 수 없음).

---

편집하다:

질문에 답하려면 :

1. 예, 여러 번 콜백을 제거 할 수 있습니다. 예를 들어 재시도 논리, distinctUntilChanged 및 다음과 같은 많은 기타 항목을 사용하여 다음과 같이 할 수 있습니다.

   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);

좀 더 구체적으로 만들려면 David Nolen의 게시물에있는 코드를 여기 에있는 RxJS FRP 예제와 비교 하십시오.

---

여기에 제한된 예제 (CSP의 이점을 보여주기위한 것임)에 대해 FRP와 CSP를 비교하는 게시물이 있으며 마지막에는 결론이 있습니다. http://potetm.github.io/2014/01/07/ frp.html

참고URL : https://stackoverflow.com/questions/20632512/comparing-core-async-and-functional-reactive-programming-rx