Why RxSwift may NOT be the solution you are looking for.

Not the solution I’m looking for.

Goodbye World!

With code snippet as follows:

let searchResults = searchBar.rx.text.orEmpty.throttle(0.3, scheduler: MainScheduler.instance).distinctUntilChanged().flatMapLatest { query -> Observable<[Repository]> inif query.isEmpty {return .just([])}return searchGitHub(query).catchErrorJustReturn([])}.observeOn(MainScheduler.instance)

Here is how I do it

With following code snippet:

rsTf.rxEndEditing ~< action{ (s, vc) in
// some string checking of s omited for clarity
api.search.withParam("q", s).loadIfNeeded()?.onNewData{ e in vc.data = e.json[P.items].arrayValue }}

whereas rsTf is an UITextField subclass instance that conforms to UITextFieldDelegate. It calls action closure whenever it sees fit using property observer.

rxEndEditing: Rx<String> is a custom event I created to bridge property observer and action closure (with custom operator ~<), and is a property in rsTf. Note that its generic type is the actual message type instead of some abstract “Observable” type.

data is the dataSource for the tableview, and it triggers tableview reload by another property observer.

Game over man, Game over.

I don’t see, at least in this rather trivial example, any way RxSwift can beat my solution.

I get to use dedicated networking library as it is without worrying about Rx-fy them.

I start with an event source with concrete message type (String as opposed to Observable<Repository>), which allows me to do type-safe functional mapping, and eventually arrive at action sink in which I update VC’s internal state.

I don’t need to care any of the stream control bullshit.

I use standard Swift features such as property observers instead of KVO or some other black magic.

The framework in total is less than 100 lines.

Developer can create his own event source, use whatever custom UI class, even extend the framework since it is less than 100 lines. Best of all, learning curve is non-existent. I mean, look at above code, create some Rx event source, bridge it over to action closure, and back to usual way of writing imperative codes in VC.

From my day-to-day experience working as iOS developer, I never need an event source that sends a continuous stream of events for which I have to monitor and take useful parts out of it.

But from my day-to-day experience working as iOS developer, I need an event source to give me exactly what I wanted when I asked for or expected it. I want no surprises, no needle in haystack.

Property observer is the key to all of this

It boggles mind that when I search RxSwift repo, I can’t find the clear usage of property observer. Either it is buried in some mystery box or not used at all. If it were the latter, how do you call a Swift reactive framework without using Swift’s most prominent reactive feature?

But keep in mind that I’m not an expert on RxSwift, so take it with a grain of salt.

Bottom line

You can easily find materials on why and how to use RxSwift. But it is a lot harder to find counter arguments on why you should not use it other than its difficulty.

I’m here to tell you, from my experience, RxSwift may not be the solution you are looking for.

Casual iOS developer