Bind, Drive, asDriver

Bind:

bind(to:) vs drive(onNext:) 차이점 정리

Rx에서는 UI 바인딩을 위해 bind(to:)와 drive(onNext:)를 자주 사용하게된다.
두 메서드는 비슷해보이지만, 차이점을 명확하게 알기위해 정리!

---

공통점

• 둘 다 UI 바인딩용으로 사용
• RxCocoa에서 제공하는 UIControlProperty, Driver, Binder 등과 함께 사용

---

bind(to:)

• RxSwift의 기본적인 바인딩 메서드
• Observable 또는 ControlProperty → Binder 로 값 전달
• 백그라운드 스레드에서도 작동 가능

  textField.rx.text
      .bind(to: viewModel.inputText)
      .disposed(by: disposeBag)

---

drive(onNext:)

• RxCocoa에서 제공하는 Driver 타입 전용 바인딩 메서드
• MainScheduler에서만 동작
• UI 바인딩에 가장 안전함

  viewModel.title
      .asDriver(onErrorDriveWith: .empty())
      .drive(self.rx.title)
      .disposed(by: self.disposeBag)

---

asDriver()란?

• Observable을 UI 바인딩에 적합한 Driver로 변환하는 연산자
• Driver는 subscribe(onNext:) 대신 drive(onNext:)로 UI에 바인딩 가능
• 주로 다음 특성을 갖는 UI 바인딩 전용 스트림 생성 시 사용

⠀

Driver의 조건

조건	설명
MainScheduler에서 동작	UI 업데이트 시 필수
에러를 방출하지 않음	.onError 없음, 안전
share(replay:1) 내장	최신 값을 캐시하여 재구독 시 전달
Hot Observable	구독 시점과 관계없이 같은 스트림 공유

다양한 변환 방식

메서드	설명
asDriver(onErrorJustReturn:)	에러 발생 시 기본값 전달
asDriver(onErrorDriveWith:)	에러 발생 시 대체 Driver로 전환
asDriver { error in … }	클로저를 통해 유연한 처리 가능

---

비교 표

항목	bind(to:)	drive(onNext:)
사용 대상	일반 Observable, Binder, Relay	Driver 타입 전용
에러 처리	❌ onError 시 크래시 가능	✅ 에러 방출하지 않음
스레드	아무 스레드	MainScheduler 전용
주 사용 용도	일반 바인딩	UI 안전 바인딩
DisposeBag 필요 여부	✅ 필요	✅ 필요

---

상황별 추천

상황	추천
UI 업데이트를 바인딩할 때	✅ drive()
비 UI 로직이나 Relay 바인딩	✅ bind()
백그라운드에서도 바인딩 필요 시	✅ bind()
UI + 스레드 안정성 + 에러 무시 필요	✅ drive()

---

요약

• bind(to:): 일반 바인딩에 적합하지만, 에러와 스레드에 주의
• drive(onNext:): UI 바인딩에 특화된 안전한 방법

UI 업데이트에는 Driver + drive() 조합이 가장 안전한 선택이라고 한다.
기존에는 bind(to:) 위주로 사용했었는데, 더 명확하게 분리하여 사용하도록 노력해야겠음!