Reactive, declarative code is sequentially cohesive: you have a sequence of events and reactions to events, and it’s pieces are tied together real close. The processing chain itself is then a function or feature of the app. The chain of operators is a thing itself; the step-by-step transformation is then reified into a sequence in one place: it has a beginning, an end, a sequential order of steps.
Continue reading …
In The Archive, people relying on character composition to enter their text noticed that the auto-saving routing got in the way and aborted the composable editing mode. This affects e.g. Chinese or Japanese character input on macOS, but also when you hit a composable accent like ´
after which the text editor waits for another character to put underneath the accent.
Continue reading …
Instead of writing view model types that expose the input and/or output ports as properties, consider writing free functions that are the transformation. This reminds me of Ken Scambler’s proposal to get rid of test doubles through side-effect free function composition. One of his examples, simplified, goes like this: Instead of testing what customer.pay(amount, wallet)
does in your tests by mocking the wallet
object, you rewrite Wallet
as a value object and change pay
to return the effect.
Continue reading …
Last year, I had a full-time job from May until November and haven’t had much time to prepare for Mojave. Then it hit hard, and I am still tweaking my apps to look properly in Mojave’s Dark Mode. I welcome that macOS offers two modes now, .aqua
and .darkAqua
in programmer parlance. Because then I don’t have to implement a homebrew solution in all my writing applications.
Continue reading …
Say you have a collection of radio buttons. They’re NSButton
instances, and NSButton
inherits from NSControl
. Radio buttons’s mutual exclusivity is implemented by … With the correct setup, you can set 1 out of 100 radio buttons to .on
and have the previous selection turned off for you automatically. That’s neat.
Continue reading …
I wanted to handle a file loading error in a consumer of an RxSwift Observable sequence. But if the sequence itself produces an .error
event, it completes. After fiddling around for a while, I decided to simply use the Result
enum and ended up with Observable<Result<Theme, ThemeError>>
.
Continue reading …
To improve my note editing app The Archive’s responsiveness, I want to find out when the user is actively editing a note. Here’s how to create the idle switch in RxSwift/RxCocoa. A simple enum of .typing
and .idle
will do for a start. Of course, NSTextViewDelegate
provides a textDidChange(_:)
callback to hook into; it’s based on a notification, so you can also subscribe to the NSText.didChangeNotification
directly if you don’t want to use a delegate. That’s the input signal I’m going to use.
Continue reading …
So here’s what I learned so far about the building blocks of reactive UI components from peeking at the RxCocoa source. UI components in general can have properties (read/write), input ports (read), and output ports (write). Classic UIKit/AppKit output ports would be delegate calls; classic input ports would be commands like display(banana:)
that you probably write every day or so.
Continue reading …
Say you are like me and work with ReSwift for unidirectional data flow goodness and employ RxSwift for your reactive cravings. You want to dispatch a ReSwift.Action
when an RxSwift.Observable
signal produces a new value. How do you write tests for that wiring? In code, it could look like this:
Continue reading …
I dabble with RxSwift right now. Figuring out how to write tests for pure functions and reactive code, I tried to write an assertion for incoming events: Doesn’t compile because equating arrays with Optional<URL>
in them won’t. In other words, [Recorded<Event<URL>>]
(non-optional) would work.
Continue reading …