Reactivecocoa: Controls as binding targets and signals

[andersio]

The majority of controls consumes only one single type of values. This makes me wonder if we might conform these controls to BindingTargetProtocol or even SignalProtocol to reduce boilerplate for common usage.

Not saying that we should ditch binding targets in .reactive, but we might allow specific subclasses to expose a "default" binding target and signal.

titleLabel.reactive.text <~ viewModel.title
viewModel.title <~ titleLabel.reactive.textValues

versus

titleLabel <~ viewModel.title
viewModel.title <~ titleLabel

[liscio]

I'd say this is probably not necessary, however if it doesn't interfere with the ability to expose >1 value (i.e. I can do someTextControl <~ someSignal in addition to someTextControl.attributedText <~ someSignal) then I'm indifferent.

[andersio]

Yeah, options are still provided via .reactive, just that the controls may declare one as the default. Say UILabel and UISwitch declare text and isOn as their defaults, respectively. Not something that is life or death though.
¯_(ツ)_/¯

[mdiep]

How about adding overloads of <~ for this?

// simplified because I'm writing in the browser 🙃
public func <~ (lhs: UILabel, rhs: Signal<String>) {
    lhs.reactive.text <~ rhs
}
public func <~ (lhs: UILabel, rhs: Signal<NSAttributedString>) {
    lhs.reactive.attributedText <~ rhs
}

That would let us set text and attributedText without extending UILabel.

It's also kinda need that you could update your view model type and it would just do the right thing.

[sharplet]

I think RAC is the first release to really make <~ shine, so it's reasonable to expect that its usage will go up. So I'm a little concerned about getting too eager with the operator overloads, because it could degrade compile time performance pretty quickly.

Some anecdotal experience to back that: on my current project we're using an Auto Layout wrapper that overloads a bunch of standard operators for specifying constraints in code. So I've felt what it's like to have methods that take 5 or 10 seconds to compile (writing all constraints in code tends to result in long methods) — and I'm a little shy about it! 😬

Granted, I haven't done the maths on this, so we might be nowhere near that critical mass yet.

[mdiep]

Measuring the compile-time impact sounds like a great idea. 👍

[andersio]

We can define them by extending the type, instead of introducing global overloads. I am not sure if the type checker improvements are already in place, but that's the direction.

https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md
One of the motivating factors for these named methods was to make the operators generic and reduce the number of concrete global overloads, which would improve the type checker's performance compared to individual concrete overloads for each conforming type. [...]