Can I get out of callback hell with RxSwift? - swift

Question

I heard that I can get out of callback hell using RxSwift.
But I don't have an idea how to improve callback hell.
The samples below need to be called in the order getItem1() -> getItem2() -> getItem3()
Is there a way out of this callback hell using RxSwift?
class MyItem {
// MARK: - Public
// Callback hell
public func getMyItem(success: #escaping (String) -> Void, failure: #escaping (Error) -> Void) {
self.getItem1(success: { [weak self] item1 in
self?.getItem2(item1: item1, success: { [weak self] item2 in
self?.getItem3(item2: item2, success: { item3 in
success(item3)
}, failure: { err3 in
print(err3)
failure(err3)
})
}, failure: { err2 in
print(err2)
failure(err2)
})
}, failure: { err1 in
print(err1)
failure(err1)
})
}
// MARK: - Private
private func getItem1(success: #escaping (String) -> Void, failure: #escaping (Error) -> Void) {
// Request to sever
}
private func getItem2(item1: String, success: #escaping (String) -> Void, failure: #escaping (Error) -> Void) {
// Request to sever
}
private func getItem3(item2: String, success: #escaping (String) -> Void, failure: #escaping (Error) -> Void) {
// Request to sever
}
}
I'm waiting for your answer to teach me.

Answer 1

Your sample, using RxSwift, would look like this:
class MyItem {
// MARK: - Public
public func getMyItem() -> Observable<String> {
getItem1()
.flatMap(getItem2(item1:))
.flatMap(getItem3(item2:))
.do(onError: { print($0) })
}
}
private func getItem1() -> Observable<String> {
// Request to server
}
private func getItem2(item1: String) -> Observable<String> {
// Request to server
}
private func getItem3(item2: String) -> Observable<String> {
// Request to server
}
There are seven different systems used in iOS code to push data from one object to another:
closures
target/action (UIControl aka IBAction)
delegates
notifications (NotificationCenter)
KVO
setting variables
sub-classing abstract base classes
A lot of the complexity of writing an application comes from trying to integrate these various systems into a unified whole. Each of the systems individually is simple to use, but weaving them together makes our code complex. One of the benefits of using RxSwift is that it wraps all of the above systems into a single powerful mechanism, thus making our code less complex overall.
Knowing the above gives a clue on how to go about integrating RxSwift into an existing project. If RxSwift can replace all those other technologies, then to integrate means to replace them with it. Once this is done, we will be able to make the code more declarative and less complex.
From Integrating RxSwift into Your Brain and Code Base

Answer 2

If for some reason you don't want to change the signatures of any of the functions you have, then you could do something crazy like this:
public func getMyItem(success: #escaping (String) -> Void, failure: #escaping (Error) -> Void) {
_ = rx_(self.getItem1)
.flatMap(rx_(self.getItem2))
.flatMap(rx_(self.getItem3))
.do(onError: { print($0) })
.subscribe(onNext: success, onError: failure)
}
The above uses the following support functions (all of these are free functions. Do not put them in a class.)
func rx_<A, B>(_ fn: #escaping (A, #escaping (B) -> Void, #escaping (Error) -> Void) -> Void) -> (A) -> Observable<B> {
{ input in
.create(observe(curry(fn, input)))
}
}
func rx_<A>(_ fn: #escaping (#escaping (A) -> Void, #escaping (Error) -> Void) -> Void) -> Observable<A> {
.create(observe(fn))
}
func curry<A, B>(_ fn: #escaping (A, #escaping (B) -> Void, #escaping (Error) -> Void) -> Void, _ a: A) -> (#escaping (B) -> Void, #escaping (Error) -> Void) -> Void {
{ success, failure in
fn(a, success, failure)
}
}
func observe<A>(_ fn: #escaping (#escaping (A) -> Void, #escaping (Error) -> Void) -> Void) -> (AnyObserver<A>) -> Disposable {
{ observer in
fn(singleObserve(observer), observer.onError)
return Disposables.create()
}
}
func singleObserve<A>(_ observer: AnyObserver<A>) -> (A) -> Void {
{ element in
observer.onNext(element)
observer.onCompleted()
}
}
I don't recommend this sort of thing for production code. IMO, something like the above trades callback hell for abstraction hell, but it's a fun exercise.