switchMap을 사용할 때 권장되는 패턴은 무엇인가요?

Q1: switchMap을 사용할 때 권장되는 기본 패턴은 무엇인가요?
A1: switchMap은 내부 옵저버블이 새로 생성될 때 이전 옵저버블의 구독을 자동으로 취소합니다. 따라서, 비동기 연속 작업에서 이전 요청 결과가 불필요할 때 주로 사용합니다. 기본 패턴은:
```typescript
sourceObservable.pipe(
switchMap(value => innerObservable(value))
)
```
여기서 `innerObservable(value)`는 주어진 값에 따라 새로운 옵저버블을 반환합니다.

---

Q2: switchMap 사용 시 주의할 점은 무엇인가요?
A2: switchMap은 새로운 값이 들어올 때 이전 내포 옵저버블 구독을 취소하므로, 이전에 실행중이던 비동기 작업 결과가 무시됩니다. 뒤늦게 완료되는 작업 결과가 필요하거나 누적해야 하는 상황엔 적합하지 않습니다.

---

Q3: switchMap과 다른 연산자들과의 조합 시 권장되는 패턴은?
A3: 보통 `filter`, `debounceTime` 등으로 이벤트를 선별하고 제한한 뒤 switchMap을 적용해 불필요한 요청을 줄입니다. 예:
```typescript
input$.pipe(
filter(value => value.length > 2),
debounceTime(300),
switchMap(value => httpRequest(value))
)
```

---

Q4: switchMap 내부에서 예외처리를 권장하는 방법은?
A4: switchMap 내부에서 발생할 수 있는 에러를 `catchError`로 처리하는 것이 좋습니다. 예를 들어,
```typescript switchMap(value => httpRequest(value).pipe(
catchError(error => of(defaultValue))
))
```
이렇게 하면 에러 발생 시 스트림이 종료되지 않고 계속 동작할 수 있습니다.

---

Q5: switchMap을 사용하여 HTTP 요청을 취소하는 패턴은?
A5: HTTP 요청과 같은 비동기 처리에서 이전 요청을 취소하려면 switchMap을 사용하면 됩니다. 백엔드로부터 응답을 기다리는 동안 새로운 요청이 들어올 때 자동으로 이전 요청을 취소하므로, 불필요한 트래픽과 상태관리 문제를 줄일 수 있습니다.

---

Q6: switchMap 대신 concatMap, mergeMap, exhaustMap과 비교했을 때 권장되는 사용 상황은 무엇인가요?
A6:
- switchMap: “가장 최신 작업만 필요”할 때, 이전 작업은 무시 가능.
- concatMap: 순서대로 모두 처리해야 할 때.
- mergeMap: 병렬 처리 가능, 모든 요청을 취소하지 않고 처리할 때.
- exhaustMap: 먼저 들어온 작업이 끝날 때까지 무시할 때.
따라서 “사용자 입력 기반 자동완성” 등 최신값 연산이 필요한 경우 switchMap 권장.

---

요약:
- 입력값 변경시 이전 비동기 작업 취소 필요할 때 switchMap 활용
- 전처리(`filter`, `debounceTime`)와 결합하여 불필요 동작 줄임
- 에러 방지를 위해 내부 catchError 사용 권장
- HTTP 요청 취소 및 최신 데이터 표시 상황에 적합
- 작업이 누적되거나 모두 처리되어야 하는 상황엔 적절하지 않음

이런 패턴을 유지하면 switchMap을 효과적이고 안전하게 사용할 수 있습니다.

switchMap은 RxJS에서 매우 유용한 연산자로, 주로 Observable이 방출하는 값에 따라 내부 Observable을 바꾸고 이전에 구독한 Observable을 자동으로 취소(cancel)할 때 사용합니다.

하지만 switchMap을 사용할 때 권장되는 패턴과 주의사항이 있습니다.

아래에 자세히 설명합니다.

1. 내부 Observable은 반드시 완결되는 스트림이어야 한다 switchMap의 목적은 구독을 새로운 내부 Observable로 전환하는 것이므로, 내부 Observable이 무한히 emit하지 않고 적절히 완료(complete)되는 Observable이어야 합니다.

예) HTTP 요청 Observable처럼 한 번 응답하고 완료되는 스트림이 이상적입니다.

만약 내부 Observable이 완료되지 않는 무한 스트림이라면, switchMap이 새로운 Observable로 전환되더라도 이전 스트림이 취소되면서 리소스 누수나 예상치 못한 동작이 발생할 수 있습니다.



2. Observable 변환 시 매핑 함수는 즉시 Observable을 반환해야 한다 switchMap 내부 매핑 함수에서는 무조건 Observable을 반환해야 하며, 비동기 처리를 할 때는 Observable 생성에 신경 써야 합니다.

예) `switchMap(value => httpClient.get(...))` 즉시 Observable을 반환하여 내부 스트림을 전환하는 방식이어야 하며, Promise나 콜백을 그냥 넣으면 안 됩니다.



3. 기본적으로 앞선 요청을 취소하고 최신 데이터만 반영하는 경우에 사용 switchMap은 이전 내부 Observable을 취소해버리므로, 예를 들어 검색창 입력에 따른 자동완성 기능 구현 시 사용하면 강력합니다.

입력을 빠르게 치면 이전 요청이 취소되고 마지막 입력 기준 결과만 받아 옵니다.

이 패턴은 “사용자 입력에 따른 최신값 반영”에 매우 효과적입니다.



4. 에러 핸들링은 내부 Observable 또는 외부에서 별도로 처리해야 한다 switchMap 내부에서 발생하는 에러가 외부 스트림 전체를 중단시키지 않게 하기 위해서는 내부 Observable에서 catchError 등을 잘 적용하거나 switchMap 밖에서 에러를 처리하는 로직을 설계하는 것이 좋습니다.



5. 내부 Observable이 너무 빨리 바뀌어도 안전하게 처리해야 한다 switchMap은 내부 Observable이 아직 완료되지 않았는데도 새로운 값이 들어오면 이전 스트림을 즉시 취소합니다.

따라서 “취소가 가능한” Observable인지, 취소 시 의도치 않은 부작용이 생기지는 않는지 반드시 확인해야 합니다.



6. 필요에 따라 다른 연산자와 조합해서 사용 예를 들어, `debounceTime`과 함께 사용하여 빠른 연속 입력을 필터링하거나, `distinctUntilChanged`로 입력값이 실제로 변경된 경우에만 switchMap을 실행하도록 해 불필요한 내부 Observable 생성과 취소를 방지할 수 있습니다.



7. 가능한 한 최소화된 내부 Observable 생성 로직 내부 Observable을 생성하는 복잡한 로직을 switchMap에 직접 넣기보다, 별도의 함수로 분리하여 가독성과 재사용성을 높이는 것이 좋습니다.

--- 요약 - switchMap 내부에는 완료되는 Observable을 반환한다.

- 이전 Observable은 자동 취소되므로, 취소 시 부작용이 없는 구조여야 한다.

- 텍스트 입력, API 요청 등 “마지막 이벤트만 처리”해야 하는 곳에 적합하다. - debounceTime, distinctUntilChanged와 조합해 불필요한 실행을 줄인다. - 에러는 내부 또는 외부에서 별도로 처리한다.

- 내부 Observable 생성 로직은 명확하고 간결하게 작성한다.

이런 패턴을 따르면 switchMap의 장점을 최대한 활용하면서도 예기치 않은 문제를 예방할 수 있습니다.