RxNot

Chris Adamson:

It’s not like iOS isn’t meant to deal with asynchronous events. In fact, it has lots of different techniques… all mutually incompatible, owing to the long development of the Cocoa and Cocoa Touch APIs over the years, and the legacy of Objective-C.

[…]

So now let’s look at how ReactiveX deals with this. In Rx, things that change over time are offered as observables. […] So, where’s the rub? For starters, it takes a long time to get the hang of Rx, both to get into its mindset (it sucks when you just need to get the current value of something, but it’s an observable, so there’s no real concept of a “current” value). And then there are all the operators. Follow that link to the operators that I linked a few paragraphs back. There are over 70 of them.

[…]

In practice, there are lots of ways to mess this up. Are you right to only want one event? What if you forget to capture self weakly? The worse problem is when your closure is never called: setting breakpoints in this code will do nothing, so it’s a hair-pulling exercise to figure out if fooObservable is not producing events, or if your chain is screwing them up somehow.

[…]

In my experience, Rx turns out to be far more costly than it would originally appear from the propaganda. I can’t speak for my ex-employer of course, but my own takeaway is that 1) adopting Rx can take way longer than you’d expect, 2) RxSwift seems to really slow down the Swift compiler (possibly because of having to do a bunch of type inference through those chains of Rx operators).

Mark Lilback:

I don’t buy the idea of replacing everything with it. But use the right tool for the right job. For chained operations it is better than promises/futures and much better than callbacks/closures.

iOS iOS 10 Programming ReactiveCocoa Swift Programming Language

2 Comments RSS · Twitter

Leave a Comment

Name

E-mail (will not be published)

Web site

Δ