Why use RxSwift?

This article, part zero of the RxSwift source code parsing series, will not introduce the advantages of RxSwift too much. Because since the reader has begun to read RxSwift source, it is necessary to have a certain understanding of RxSwift, so here is only a simple talk about the author’s feelings.

The author believes that RxSwift, as a responsive programming framework, brings the first benefit is the convergence of logic. In the normal APP development process, we will deal with a large number of user interaction events, and will involve a large number of logical jumps, through closures, agents, notifications, KVO and other ways to transfer data. This will lead to the dispersion of business logic, the same business chain is likely to be scattered in multiple classes, thus bringing difficulties to debugging and troubleshooting, but also easy for the emergence of bugs hidden trouble. With RxSwift, logical aggregation can be achieved through the various operators provided by RxSwift.

Another benefit of RxSwift lies in the responsive programming philosophy, which describes all events as a listening sequence and provides a large number of operators with different functions. Data can be obtained, converted, combined and bound by declarative statements.

Second, why to read RxSwift source code

Here, I don’t want to say too much about the benefits of reading the source code, because it is all jargon, just put a picture:Because RxSwift is a highly encapsulated framework, the code is highly abstract, and the call chain becomes extremely complex with different operators, which presents a huge challenge to debug. Yes, in order to be able to debug RxSwift, this is the author read RxSwift source the most original motivation.

Iii. Core concepts of RxSwift

RxSwift has three core concepts: Observable, Observer and Operator.

Observable

Observable, there are two protocols. ObservableConvertibleType and ObservableConvertibleType.

public protocol ObservableConvertibleType {
  
    associatedtype Element

    func asObservable() -> Observable<Element>
}
Copy the code

public protocol ObservableType: ObservableConvertibleType {
    func subscribe<Observer: ObserverType>(_ observer: Observer) -> Disposable where Observer.Element == Element
}

extension ObservableType {
    
    public func asObservable() -> Observable<Element> {
        Observable.create { o in self.subscribe(o) }
    }
}


Copy the code

ObservableConvertibleType protocol defines a method that asObservable (), returns a observables.

ObservableType defines a subscribe<Observer: ObserverType>(_ Observer: Observer), that is, subscribe to an Observer.

An Observable is a class that follows ObservableType.

An Observable is an Observable that can be subscribed to by calling the Subscribe method.

Observer

An Observer is an Observer, which is also implemented through a protocol (ObserverType) :

public protocol ObserverType {
    associatedtype Element
    func on(_ event: Event<Element>)
}
Copy the code

ObserverType defines an on(_ event: event) method with an event type:

@frozen public enum Event<Element> {
    /// Next element is produced.
    case next(Element)

    /// Sequence terminated with an error.
    case error(Swift.Error)

    /// Sequence completed successfully.
    case completed
}
Copy the code

/// Sequence terminated with an error. case error(Swift.Error)

/// Sequence completed successfully. case completed }

This is an enumeration that defines three different types of events in RxSwift:

.next: a normal event

.error: indicates an error event

.completed: A completion event

So the basic core logic of RxSwift is that an Observable subscribes to an Observer and passes events via the Observer’s on(_ event:) method when they are generated. As to how the event is generated, we will examine it in the next article.

Operator

The third concept in RxSwift is called Operator.

The first two concepts address the generation and delivery of events, but they do not solve the problem that the generated events may not be what we need, and the operators do just that.

For example, if we have a sequence that produces ints, but we might want a sequence of String events, and we want the String to be the result of some conversion of ints, we need a map operator

Observable<Int>.of(1,2,3,4).map {value in return String(value*2)}. { str in print(str) }) .disposed(by: disposeBag)Copy the code

Using the map operator, we convert the Int sequence 1,2,3,4 sent by the original sequence into the String sequence “2”, “4”, “6”, “8”. Other common operators include filter, flatMap, compactMap, withLatestFrom, Skip, etc., which will be analyzed in subsequent articles.

4. Core logic of RxSwift

In fact, through the introduction of the three core concepts of RxSwift above, we have roughly understood the core logic of RxSwift:

An Observable subscribes to an Observer after converting an Operator to convert and bind events.

Five, the conclusion

As the first of a series of articles, this paper simply introduces the core concepts and core logic of RxSwift. As for its specific implementation logic, we will analyze it step by step in the subsequent articles. Please look forward to it.