Say, you just learned RxSwift and all about subscribeNext. You have a series of Harry Potter related service calls to make and they affect each other. Let’s also say they all return the same type of Observable<Person>. So, you start to call these services one after another using subscribeNext.

The indention of calls is known as the Pyramid of Doom. This is a case of not using all of the power that RxSwift offers. If we inject flatMapLatest into the mix instead of all subscribeNext calls, we get the following:

Not only is the flatMapLatest approach easier to read, but one can see easily where the addDisposableTo(disposeBag) should be added at the end to manage the memory.

This concept is also covered in the RxSwift Tips document. Enjoy all that RxSwift has to offer!

RxSwift 2.1.0 is out! Congrats to kzaher and all the members.

Since things moved fast over the winter holidays in RxSwift, you might see some changes that happened between 2.0.0-beta.4 and 2.0.0 that interest you if you haven’t switched yet. When moving from the latest RxSwift beta to 2.0.0, the 2.0.0-rc.0’s Deprecated section of the Change Log may answer some compilation issues you face.

Straightforward changes were needed for my work. For example, I needed to stick Observable in front of create. As covered in the Change Log:

Deprecates free functions in favor of Observable factory methods

An interesting one involves Variable:

Deprecates Variable implementing ObservableType in favor of asObservable()

Looking at GitHubSignup “UsingVanillaObservables > 1″ and “UsingDriver > 2″ in the RxExample code, I see the answer to my questions and so much more. There is an emphasis on using Driver as opposed to Variable objects. Although, a deep dive into Driver is a whole other topic.

In regards to 2.1, the changes from 2.0 to 2.1 are minimal and had no impact on my work.

Enjoy the new stuff!

Curiosity is a powerful thing. When I saw this RxSwift Driver being discussed on RxSwift Slack and read the helpful RxSwift GitHub issue “Need better explanation / examples for Driver” submitted by Florent Pillet, it seemed helpful to capture what I saw.

As Carlos García shared on the GitHub issue:

One should think of the following:

as the same as:

Krunoslav Zaher aka kzaher on the RxSwift slack community said that it is a combination of: “main thread + shared subscriptions + no errors.” He goes on to say that shareReplay(1) is a shared subscriptions example. Carlos adds there are several examples in RxExample.

kzaher sums it all up nicely by sharing:

Yeah, it’s just a tiny builder/dsl for Observables. I think this should help me and others a lot with ensuring you can safely bind values to UI.

Using Driver is optional, but it helps the compiler catch things and will help emphasize things that might have been missed. As kzaher put it:

..and warn me when I’ve forgot to handle unexpected errors, or binding from background thread or doing something I should have when dealing with UI applications.

You may want to keep an eye on the RxSwift documentation as it grows and develops over time. Specifically, this Units document. Driver sounds exciting and I look forward to trying it in-depth in the near future!

Jan 2, 2016 Update: The Units document has been updated and much more has been added to it. Good stuff!

Do you speak RxSwift? Do you know the concepts, words and operators? Here is a snapshot summary of many of them.

Some of the RxSwift Concepts from Getting Started

An Observable is a definition of: 

• “..how the sequence is generated..”
• “..what parameters are used for element generation..”

Disposing

“..release all of the resources that were allocated to compute upcoming elements..”

Observable aka Sequence

• One after another, the Observable sends a Next (element), Error, or a Completed
• What stops them from coming? An Error, Completed or dispose the subscriptions.

Observer

Subscribes to Observables

Subject

(Source: Rx.playground)

Terse mode: “acts both as an Observer and as an Observable”

Full mode: “A Subject is a sort of bridge or proxy that is available in some implementations of ReactiveX that acts both as an observer and as an Observable. Because it is an observer, it can subscribe to one or more Observables, and because it is an Observable, it can pass through the items it observes by reemitting them, and it can also emit new items.”

Operators

There is a list sorted by functionality at https://github.com/ReactiveX/RxSwift/blob/master/Documentation/API.md#rxswift-supported-operators

Operator Types:

(Sources: Rx.playground and github docs)

• Combination operators – startWith, combineLatest, merge, switchLatest, zip; “Operators that work with multiple source Observables to create a single Observable”
• Conditional and Boolean Operators – takeUntil, takeWhile – “Operators that evaluate one or more Observables or items emitted by Observables.”
• Connectable Observable Operators – multicast, replay, replayAll, publish – “like an ordinary Observable yet only when its connect() is called does it emit”
• Error Handling Operators- catchError, retry – “Operators that help to recover from error notifications from an Observable.”
• Filtering Observables – distinctUntilChanged, filter, take; “Operators that selectively emit items from a source Observable.”
• Mathematical and Aggregate Operators – concat, reduce – “Operators that operate on the entire sequence of items emitted by an Observable”
• Observable Utility Operators – doOn, subscribe, subscribeNext, subscribeCompleted, subscribeError; “toolbox of useful Operators for working with Observables”
• Transforming Observables – map / select, flatMap, scan; “Operators that transform items that are emitted by an Observable”
• Units – “purpose of Driver unit is to ensure the underlying observable sequence has the following properties”: It “can’t fail”, “main thread”, and more.

Schedulers

Schedulers are an abstraction away from what does work (queues / threads).

RxSwiftCommunity

By the way, the RxSwiftCommunity bears checking in on from time to time. Action is listed there and it comes up often in the RxSwift Slack community and at least once in Stack Overflow. Just like the adoption of RxSwift, I sense the community will grow over time.

Update: If one looks at the code commits done for the RxSwiftCommunity website, one can easily see lots of activity going on.

Looking at some RxSwift test code, I knew it could be better. As I shared with Krunoslav Zaher aka kzaher in the RxSwift Slack community:

I feel the opportunity for improvement down to my soul.

Test Code
He kindly helped me simplify some RxSwift test code. He suggested that instead of:

Do something like this:

To make that work, I had to change the oldBakeryServiceSpy from something like this:

To this:

This also allowed us to use failWith. As in:

 

More kzaher Words of Wisdom

if you are mocking, just use just, sequenceOf, [].toObservable()

It was also shared that TestScheduler will be released soon and one can look at the unit tests.

What about Simplifying Our Use of the DisposeBag?

As a result of what we read in the README, we use DisposeBag objects often. As kzaher shared:

If you use operators, that will reduce the amount of dispose bags significantly. We handle all of disposing for you. You only dispose terminal endpoints where you do “subscribe”

All Part of the Game of Learning

Slowly things are improving. Although it’s all part of the game of learning something new, I think it would serve all well if someone created a game called “Simplify This RxSwift code.” I know I would happily play it.

This is some of what I did to learn FRP / RxSwift:

• Watched and read https://realm.io/news/swift-summit-javier-soto-futures/ to get some basic concepts
• Watched and read https://realm.io/news/altconf-ash-furrow-functional-reactive-swift/  to get some more concepts reinforced
• Ran and examined the GitHubSignup example at https://github.com/ReactiveX/RxSwift/tree/master/RxExample/RxExample/Examples/GitHubSignup
• and then RxSwift documentation in this order,
  • README​
  • Getting Started
  • API

The RxSwift Slack Community is awesome: http://slack.rxswift.org They guided me to these resources.

Besides playing around with lots of code, that’s the meat of what I did. I know every individual has his or her own path of learning. However, I figured I would share a terse version of mine in case it helps.

Update December 31, 2015: I would watch Functional Reactive Programming with RxSwift by Max Alexander first.