RxNot
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
selfweakly? 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 iffooObservableis 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).
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.
2 Comments RSS · Twitter
[…] to drag it across the liquidity event finish line, it’s all good) but general consensus is of the RxNot mindset that designing for maintainability is difficult enough already without seriously considering an […]
