ReactiveX - 관찰 가능 을 번역한글
ReactiveX에서 관찰자는 관찰 가능 항목을 구독합니다. 그런 다음 관찰자는 Observable이 방출하는 항목의 항목이나 시퀀스에 반응합니다. 이 패턴은 Observable이 객체를 방출하기를 기다리는 동안 차단할 필요가 없기 때문에 동시 작업을 용이하게하지만, 대신 Observable이 그렇게 할 미래의 시간에 적절하게 반응 할 준비가 된 관찰자 형태로 보초를 만듭니다.
이 페이지에서는 반응 패턴이 무엇인지, 관찰 가능 및 관찰자가 무엇인지(그리고 관찰자가 Observables를 구독하는 방법)에 대해 설명합니다. 다른 페이지에서는 다양한 Observable 연산자를 사용하여 Observables를 함께 연결하고 동작을 변경하는 방법을 보여 줍니다.
이 설명서에는 "대리석 다이어그램"이라는 설명이 함께 제공됩니다. 대리석 다이어그램이 Observables와 Observables의 변형을 나타내는 방법은 다음과 같습니다.
또한 보십시오
- 단일 — 단일 항목만 내보내는 Observable의 특수 버전
- Rx 워크샵 : 소개
- Rx 소개 : IObservable
- 관측 가능 항목 마스터링(Couchbase 서버 설명서에서)
- Andre Staltz의 Rx에 대한 2 분 소개 ( "Observable을 비동기 불변 배열로 생각하십시오.")
- Jafar Husain의 Observable 소개 (JavaScript Video Tutorial)
- Observable object (RxJS) by Dennis Stoyanov
- 콜백을 @afterecho에 의해 Rx Observable로 변환
배경
많은 소프트웨어 프로그래밍 작업에서, 당신은 당신이 작성한 지시 사항이 당신이 작성한 순서대로 한 번에 하나씩 점진적으로 실행되고 완료 될 것으로 기대합니다. 그러나 ReactiveX에서는 많은 명령이 병렬로 실행될 수 있으며 그 결과는 나중에 "관찰자"에 의해 임의의 순서로 캡처됩니다. 메서드를 호출하는 대신 "관찰 가능"의 형태로 데이터를 검색하고 변환하는 메커니즘을 정의한 다음 관찰자를 구독합니다.이 시점에서 이전에 정의 된 메커니즘은 관찰자가 준비가되면 방출을 캡처하고 응답하기 위해 관찰자가 서있는 보초로 작동하게됩니다.
이 방법의 장점은 서로 의존하지 않는 많은 작업이있을 때 다음 작업을 시작하기 전에 각 작업이 완료 될 때까지 기다리지 않고 동시에 모두 시작할 수 있다는 것입니다.
이 비동기 프로그래밍 및 디자인 모델을 설명하는 데 사용되는 많은 용어가 있습니다. 이 문서에서는 다음 용어를 사용합니다: 관찰자는 Observable을 구독합니다. 관찰 가능 (Observable)은 관찰자의 메소드를 호출하여 항목을 내보내거나 관찰자에게 알림을 보냅니다.
다른 문서 및 다른 맥락에서, 우리가 "관찰자"라고 부르는 것을 때때로 "가입자", "감시자"또는 "원자로"라고 부릅니다. 이 모델은 일반적으로 종종 "반응기 패턴"이라고합니다.
관찰자 설정
이 페이지에서는 그루비와 같은 의사 코드를 예제로 사용하지만 많은 언어로 ReactiveX 구현이 있습니다.
일반적인 메서드 호출, 즉 ReactiveX에서 일반적인 비동기식 병렬 호출이 아닌 일반적인 메서드 호출에서 흐름은 다음과 같습니다.
- 메서드를 호출합니다.
- 해당 메서드의 반환 값을 변수에 저장합니다.
- 해당 변수와 새 값을 사용하여 유용한 작업을 수행하십시오.
또는 다음과 같은 것이 있습니다.
// make the call, assign its return value to `returnVal` returnVal = someMethod(itsParameters); // do something useful with returnVal
비동기 모델에서 흐름은 다음과 같이 진행됩니다.
- 비동기 호출의 반환 값으로 유용한 작업을 수행하는 메서드를 정의합니다. 이 방법은 관찰자의 일부입니다.
- 비동기 호출 자체를 Observable로 정의합니다.
- 관찰자를 구독하여 관찰 가능한 것에 첨부하십시오 (이것은 또한 관찰 가능한 사람의 행동을 시작합니다).
- 귀하의 사업을 계속하십시오. 호출이 반환될 때마다 관찰자의 메서드는 반환 값 또는 값(Observable에서 내보내는 항목)에서 작동하기 시작합니다.
어떤 것이 다음과 같이 보입니다 :
// defines, but does not invoke, the Subscriber's onNext handler
// (in this example, the observer is very simple and has only an onNext handler)
def myOnNext = { it -> do something useful with it };
// defines, but does not invoke, the Observable
def myObservable = someObservable(itsParameters);
// subscribes the Subscriber to the Observable, and invokes the Observable
myObservable.subscribe(myOnNext);
// go on about my businessonNext, onCompleted, onError
Subscribe 메서드는 관찰자를 관찰 가능 파일에 연결하는 방법입니다. 관찰자는 다음 메서드의 일부 하위 집합을 구현합니다.
onNext- Observable은 Observable이 항목을 내보낼 때마다 이 메서드를 호출합니다. 이 메서드는 Observable에서 내보내는 항목을 매개 변수로 사용합니다.
onError- Observable은 이 메서드를 호출하여 예상 데이터를 생성하지 못했거나 다른 오류가 발생했음을 나타냅니다. 또는 . 이 메서드는 매개 변수로 오류의 원인에 대한 표시를 사용합니다.
onNextonCompletedonError onCompleted- Observable은 오류가 발생하지 않은 경우 마지막으로 호출한 후에 이 메서드를 호출합니다.
onNext
관찰 가능한 계약의 조건에 따라, 그것은 0 번 이상 호출 할 수 있으며, 그 다음 마지막 호출이 될 둘 중 하나 또는 둘 다에 대한 호출로 해당 호출을 따를 수 있습니다. 관례에 따라, 이 문서에서는 일반적으로 호출을 항목의 "배출"이라고 하는 반면, 호출 또는 "알림"이라고 합니다. onNextonCompletedonErroronNextonCompletedonError
보다 완전한 호출 예제는 다음과 같습니다. subscribe
def myOnNext = { item -> /* do something useful with item */ };
def myError = { throwable -> /* react sensibly to a failed call */ };
def myComplete = { /* clean up after the final response */ };
def myObservable = someMethod(itsParameters);
myObservable.subscribe(myOnNext, myError, myComplete);
// go on about my business또한 보십시오
수신 거부
일부 ReactiveX 구현에는 메서드를 구현하는 특수 관찰자 인터페이스가 있습니다. 이 메서드를 호출하여 구독자가 현재 구독하고 있는 관찰 가능 항목에 더 이상 관심이 없음을 나타낼 수 있습니다. 그런 다음 Observables는 (다른 관심있는 관찰자가없는 경우) 방출 할 새 항목 생성을 중지하도록 선택할 수 있습니다. Subscriberunsubscribe
이 구독 취소의 결과는 관찰자가 구독한 Observable에 적용되는 연산자 체인을 통해 다시 계단식으로 돌아가며, 이로 인해 체인의 각 링크가 항목 내보내기를 중지하게 됩니다. 그러나 이것이 즉시 발생한다고 보장되는 것은 아니며, 관찰자가 이러한 배출을 관찰하기 위해 남아있는 관찰자가 없더라도 관찰 가능한 사람이 잠시 동안 항목을 생성하고 방출하려고 시도 할 수 있습니다.
명명 규칙에 대한 몇 가지 참고 사항
ReactiveX의 각 언어별 구현에는 고유한 명명 단점이 있습니다. 정식 명명 표준은 없지만 구현 간에는 많은 공통점이 있습니다.
또한 이러한 이름 중 일부는 다른 컨텍스트에서 다른 의미를 갖거나 특정 구현 언어의 관용구에서 어색하게 보입니다.
예를 들어 명명 패턴 (예 : , , )이 있습니다. 일부 컨텍스트에서 이러한 이름은 이벤트 처리기가 등록되는 메서드를 나타냅니다. 그러나 ReactiveX에서는 이벤트 처리기 자체의 이름을 지정합니다. onEventonNextonCompletedonError
"뜨거운"및 "차가운"관측 가능
Observable은 언제 일련의 항목을 방출하기 시작합니까? 그것은 관찰 가능 (Observable)에 달려 있습니다. "뜨거운" Observable은 아이템이 생성되자마자 아이템을 방출하기 시작할 수 있으며, 따라서 나중에 해당 Observable에 가입하는 관찰자는 중간 어딘가에서 시퀀스를 관찰하기 시작할 수 있습니다. 반면에 "차가운"관찰 가능 (Observable)은 관찰자가 항목을 방출하기 전에 그것을 구독 할 때까지 기다리기 때문에 그러한 관찰자는 처음부터 전체 시퀀스를 볼 수 있습니다.
ReactiveX의 일부 구현에서는 "연결 가능"관찰 가능이라고도합니다. 이러한 Observable은 관찰자가 구독했는지 여부에 관계없이 Connect 메서드가 호출될 때까지 항목을 내보내기 시작하지 않습니다.
관찰 가능한 연산자를 통한 구성
관측 가능 항목과 관찰자는 ReactiveX의 시작에 불과합니다. 그 자체로는 표준 관찰자 패턴의 약간의 확장에 지나지 않을 것이며, 단일 콜백보다는 일련의 이벤트를 처리하는 데 더 적합합니다.
진정한 힘은 "반응 확장"(따라서 "ReactiveX")과 함께 제공됩니다 - Observables에서 방출되는 항목의 시퀀스를 변환, 결합, 조작 및 작업 할 수있는 연산자.
이러한 Rx 연산자를 사용하면 콜백의 모든 효율성 이점과 함께 선언적 방식으로 비동기 시퀀스를 함께 작성할 수 있지만 일반적으로 비동기 시스템과 관련된 콜백 처리기 중첩의 단점은 없습니다.
이 설명서는 다양한 연산자와 해당 사용 예제에 대한 정보를 다음 페이지로 그룹화합니다.
- 관측 가능 항목 만들기
Create, , //, , , 및DeferEmptyNeverThrowFromIntervalJustRangeRepeatStartTimer- 관찰 가능한 항목 변환
Buffer그리고FlatMapGroupByMapScanWindow- 관측 가능 항목 필터링
Debounce그리고DistinctElementAtFilterFirstIgnoreElementsLastSampleSkipSkipLastTakeTakeLast- 관측 가능 항목 결합
And/Then/When그리고CombineLatestJoinMergeStartWithSwitchZip- 오류 처리 연산자
Catch그리고Retry- 유틸리티 운영자
Delay, , /, , , , , , , 및DoMaterializeDematerializeObserveOnSerializeSubscribeSubscribeOnTimeIntervalTimeoutTimestampUsing- 조건부 및 부울 연산자
All그리고AmbContainsDefaultIfEmptySequenceEqualSkipUntilSkipWhileTakeUntilTakeWhile- 수학 및 집계 연산자
Average그리고ConcatCountMaxMinReduceSum- 관측 가능 항목 변환
To- 연결 가능한 관찰 가능한 연산자
Connect그리고PublishRefCountReplay- 배압 연산자
- 특정 흐름 제어 정책을 적용하는 다양한 연산자
이 페이지에는 ReactiveX의 핵심에 속하지 않지만 하나 이상의 언어별 구현 및/또는 선택적 모듈로 구현되는 일부 연산자에 대한 정보가 포함되어 있습니다.
운영자 체인
대부분의 연산자는 Observable에서 작동하고 Observable을 반환합니다. 이렇게 하면 이러한 연산자를 체인에 차례로 적용할 수 있습니다. 체인의 각 연산자는 이전 연산자의 작동으로 인해 발생하는 Observable을 수정합니다.
Builder Pattern과 같은 다른 패턴이 있는데, 특정 클래스의 다양한 메소드가 메소드의 연산을 통해 해당 객체를 수정하여 동일한 클래스의 항목에서 작동합니다. 이러한 패턴을 사용하면 비슷한 방식으로 메서드를 연결할 수도 있습니다. 그러나 빌더 패턴에서는 메서드가 체인에 나타나는 순서는 일반적으로 중요하지 않으며 Observable 연산자 순서가 중요합니다.
Observable 연산자의 체인은 체인을 시작한 원래 Observable에서 독립적으로 작동하지 않지만 체인에서 바로 전에 운영자가 생성 한 Observable에서 작동하는 각 연산자가 차례로 작동합니다.
댓글 없음:
댓글 쓰기