Would like to be able to congregate with others using and learning ReactiveCocoa. Of course I could just join/create the channel on freenode if you guys don't want to do a sort of 'official' room.

This is a sweeping refactor of the property subject and binding code, to simultaneously solve a few different problems:

1. Duplicated implementation logic
2. Confusion about which side bindings go on, how many you need to create to do things, etc.
3. ~~Confusion about how bindings don't echo values sent to them~~
4. Complexity from supporting N-way bindings

Still a huge work-in-progress, but I'd love feedback on the API. In particular, are the separate endpoint properties useful?

@Coneko @andymatuschak

We're gonna host a day of ReactiveCocoa talks and Q&A at the GitHub office during WWDC week this year.

The current plan is to do it on Tuesday, June 3rd, with a rough agenda like the following (as suggested by @dannygreg):

• Late(ish) start - ~11am
• Brief kickoff talk (I'll do a quick overview of the day)
• 2 or 3 talks (each ~ 30 mins)
• Lazy Lunch
• Panel and QA discussion
• Social/"networking" time

We'll have a proper event invitation coming soon, to which you can RSVP. However, we'd like to solicit talks from RAC collaborators.

Would anyone from @ReactiveCocoa/reactivecocoa be interested in speaking?

Resolves #1365 and #1366. Per my comments in #1369, this is intended to be a long-running branch that will eventually become RAC 3.0, supplanting the current 3.0-development work.

To get us started, I basically just subtree merged jspahrsummers/RxSwift into here, then bridged several RAC classes back and forth.

After the long discussion in #1650, I invited @NachoSoto, @andymatuschak, and @kastiglione to talk more in-depth about the Swift APIs, and specifically where they need improvement.

We had a really, really great brainstorming session, and this is the result. The good news is that we all feel pretty good about this direction, and the bad news is that everything is getting rewritten again. :trollface:

The important bits are documented on the types themselves, but here’s the handy Quick Start guide of the proposed changes:

1. HotSignal<T> will be replaced by Signal<T>. Besides the name change, these signals can now send Error and Completed events. This avoids a lot of the lifecycle weirdness that has come up with a value-only HotSignal.
2. ColdSignal<T> will be replaced by SignalProducer<T>. As the name implies, a signal producer creates Signals (via the start method). You can kind of think of the relationship as something like:
   • SignalProducer : Signal :: RACSignal : subscription
   • SignalProducer : Signal :: class : instance
3. Most of the basic operators are written in terms of Signal, but can be lifted to apply to SignalProducer instead.
4. Operators that benefit from “cold” semantics, like retry and repeat, are written in terms of SignalProducer.

The advantages here are:

• The relationship between “hot” and “cold” signals is now much more explicit and well-defined. A “cold” signal (a producer) creates “hot” signals, each of which represents a “subscription” (in RAC 2.x terms).
• Many operators only have to be written once, in terms of Signal, and can be lifted to the SignalProducer level.
• The semantics and/or difficulties of converting between “hot” and “cold” are more obvious, I think. You don’t need to swap between them on the fly, because they mean different things.
• Signal lifetime is now consistent, and completely defined by the event stream. Signal producers don’t do anything special—they really are just value types, and don’t encode any information about lifetime.

I’ll also make some notes in the changes below, to explain more specific things. Please leave feedback if you have it! :bow:

Just like last year and the year before, we want to do some kind of RAC community event during WWDC week (June 8–12).

We don't know what, though, or when. Did you particularly like either of the previous formats, or any aspects of them? Do you have any ideas for something new we should try?

I'd love to hear your thoughts! :pray:

/cc @ReactiveCocoa/reactivecocoa

Changes

General

• [x] Updated for Swift 3.0 GM.
• [x] A standalone rac_signalForSelector port.
• [x] ~~Hide the ReactiveCocoaPrivate module.~~
• [x] Adopted BindingTarget for all non-observable key paths.
• [x] Update the documentation.

The Reactive proxy

• [x] Moved all extension method and properties to Reactive.
• [x] Point to a new ReactiveSwift (pre-)release with Reactive.

CocoaAction

• [x] Consolidated the API of CocoaAction.
• [x] Parameterized CocoaAction with an assumed sender type.

Control bindings and values

• [x] Extensions for NSControl.
• [x] Text controls now expose an end-of-editing signal by default, with continuous counterparts added.
• [x] Control values are split into a pair of binding target and signal.
• [x] UIControl.reactive.trigger(for:) for all UIControlEvents.

Blocked by:

• [x] Reactive. https://github.com/ReactiveCocoa/ReactiveSwift/pull/51
• [x] Scheduler in BindingTarget. https://github.com/ReactiveCocoa/ReactiveSwift/pull/49
• [x] API Design: Exposing the control values. https://github.com/ReactiveCocoa/ReactiveCocoa/issues/3229
• [x] API Design: Control Binding API for Actions. https://github.com/ReactiveCocoa/ReactiveCocoa/issues/3233

Review

• [x] @mdiep
• [x] @NachoSoto
• Others

Let's say I have parallel work I want to do, such as downloading multiple images. Each of these downloads is represented by a SignalProducer. I create them and flatten them using the Merge strategy. When I start the outer producer and get a disposable I expected that disposing of that would also dispose of the inner producers. What actually happens is that after disposal, my outer producer stops receiving events, but the actual work being done by the inner producers continues, because they have not been disposed.

How do I get the actual work being done by the inner producers to stop? Here's some test code that illustrates the scenario:

func producerOfValues(values: [String]) -> SignalProducer<String, NoError> {
    return SignalProducer<String, NoError> {observer, disposable in
        for value in values {
            sleep(1)
            print("doing work: \(value)")
            sendNext(observer, value)
            if disposable.disposed { // 'disposed' is never true
                print("producer disposed")
                break
            }
        }
        sendCompleted(observer)
    }
}

let (signal, sink) = SignalProducer<SignalProducer<String, NoError>, NoError>.buffer(2)
let flattened = signal.flatten(.Merge)

let letterProducer = producerOfValues(["a", "b", "c"])
let numberProducer = producerOfValues(["1", "2", "3"])

sendNext(sink, letterProducer.startOn(QueueScheduler()))
sendNext(sink, numberProducer.startOn(QueueScheduler()))
sendCompleted(sink)

let disposable = flattened.startWithNext {
    print($0)
}
disposable.dispose()

Output:

doing work: a
doing work: 1
doing work: b
doing work: 2
doing work: c
doing work: 3

I've been meaning to open this issue for a while, but kept finding excuses, mainly the fact that 3.0 was far from release. That is no longer the case now.

Basically, I'd like to spearhead an effort to revamp the visual identity of RC and hopefully be done with that in time with the 3.0 final release.

For reference, here is the current logo/color palette:

I've played with the concept below a while ago, but I restarted from scratch recently after having talked to @jspahrsummers during WWDC.

Here are some of the recent sketches to get the creative juices flowing:

I'll be detailing the rest of the process in this thread.

#89

Added a lazy RACSequence class, and abstracted common APIs between it and <RACSubscribable> into a new <RACStream> protocol. I'm definitely open to better names for these guys.

RAC should be tagged before this gets merged in.

Given recent developments, how much should we allow ourselves to disregard backwards compatibility in our next release?

Is there any part of the RAC contract you would like to change or get rid of?

For example I would like to take a much more relaxed approach to evaluation, like Rx with its "you cannot assume anything about what scheduler your blocks run on unless you specify a scheduler" caveat.

On one side it would allow us to optimize for certain use cases much more aggressively, but even better it would promote functional purity when using the framework. What I want is for the lack of strict evaluation semantics not to force users of the framework to do their own serialization and rescheduling of the blocks, but rather to allow them to not care about when, where and how the blocks are executed, because the blocks would be pure functions.

I realize this can't be done because even in Swift there is no way to specify side effects or lack thereof in the type, or even thread-safety or atomicity, so I'm not suggesting we do this since it would be very confusing for the users, it's just an example of what I mean by changes in the contract.

I'm sure someone has more reasonable ideas on the matter.

Recently ReactiveSwift min deployment targets were bumped in a minor release. So now ReactiveCocoa has min iOS deployment target iOS 9 but it has ReactiveSwift ~> 7.0 that resolves to the new ReactiveSwift 7.1 that has min deployment target iOS 10. As a result I'm getting

- ERROR | [iOS] xcodebuild:  ReactiveCocoa/ReactiveCocoa/AnyObject+Lifetime.swift:2:8: error: compiling for iOS 9.0, but module 'ReactiveSwift' has a minimum deployment target of iOS 10.0

Could you please bump ReactiveCocoa min deployment targets to make it compatible with the ReactiveSwift 7.1

Code:

[self.hgWorkStyleDisposable dispose];

self.hgWorkStyleDisposable = [[[RACSignal combineLatest:@[RACObserve(devicedata_weak_, PK_workStyle),RACObserve(devicedata_weak_, hgDetailModel.settings.unit)]] deliverOnMainThread] subscribeNext:^(RACTuple * _Nullable x) {
} ];

Error #0 Thread NSRangeException Cannot remove an observer <RACKVOProxy 0x280264940> for the key path "unit" from <HGConfigureModel 0x280d25050> because it is not registered as an observer.

Stack:

CoreFoundation ___exceptionPreprocess + 164

4 Foundation -[NSObject(NSKeyValueObserverRegistration) removeObserver:forKeyPath:context:] + 196 5 ReactiveObjC -[RACKVOTrampoline dispose] (RACKVOTrampoline.m:84) 6 ReactiveObjC -[RACCompoundDisposable dispose] (RACCompoundDisposable.m:243) 7 ReactiveObjC __69-[NSObject(RACKVOWrapper) rac_observeKeyPath:options:observer:block:]_block_invoke.17 (NSObject+RACKVOWrapper.m:195) 8 ReactiveObjC -[RACDisposable dispose] (RACDisposable.m:82) 9 ReactiveObjC -[RACCompoundDisposable dispose] (RACCompoundDisposable.m:239) 10 ReactiveObjC -[RACSerialDisposable dispose] (RACSerialDisposable.m:119) 11 ReactiveObjC -[RACCompoundDisposable dispose] (RACCompoundDisposable.m:239) 12 ReactiveObjC __69-[NSObject(RACKVOWrapper) rac_observeKeyPath:options:observer:block:]_block_invoke.17 (NSObject+RACKVOWrapper.m:195) 13 ReactiveObjC -[RACDisposable dispose] (RACDisposable.m:82) 14 ReactiveObjC -[RACCompoundDisposable dispose] (RACCompoundDisposable.m:239) 15 ReactiveObjC -[RACSerialDisposable dispose] (RACSerialDisposable.m:119) 16 ReactiveObjC -[RACCompoundDisposable dispose] (RACCompoundDisposable.m:239) 17 ReactiveObjC __69-[NSObject(RACKVOWrapper) rac_observeKeyPath:options:observer:block:]_block_invoke.17 (NSObject+RACKVOWrapper.m:195) 18 ReactiveObjC -[RACDisposable dispose] (RACDisposable.m:82) 19 ReactiveObjC -[RACCompoundDisposable dispose] (RACCompoundDisposable.m:243) 20 ReactiveObjC -[RACCompoundDisposable dispose] (RACCompoundDisposable.m:243) 21 ReactiveObjC -[RACCompoundDisposable dispose] (RACCompoundDisposable.m:243) 22 ReactiveObjC -[RACSerialDisposable dispose] (RACSerialDisposable.m:119) 23 ReactiveObjC -[RACCompoundDisposable dispose] (RACCompoundDisposable.m:239) 24 ReactiveObjC -[RACCompoundDisposable dispose] (RACCompoundDisposable.m:243) 25 ReactiveObjC -[RACCompoundDisposable dispose] (RACCompoundDisposable.m:243) 26 ReactiveObjC -[RACCompoundDisposable dispose] (RACCompoundDisposable.m:243) 27 ReactiveObjC -[RACSerialDisposable dispose] (RACSerialDisposable.m:119) 28 ReactiveObjC -[RACCompoundDisposable dispose] (RACCompoundDisposable.m:239) 29 ReactiveObjC -[RACCompoundDisposable dispose] (RACCompoundDisposable.m:243) 30 ReactiveObjC -[RACCompoundDisposable dispose] (RACCompoundDisposable.m:243) 31 PetKit -[PKHomeK2CollectionViewCell handleForReuseCell] (PKHomeK2CollectionViewCell.m:84) 32 PetKit -[PKHomeDeviceBaseCollectionCell prepareForReuse] (PKHomeDeviceBaseCollectionCell.m:36)

Added the includeReturnValue to reactive.signal(for selector: Selector)

NSObject.reactive.signal(for selector: Selector, includeReturnValue: Bool = false)

Will add a return value to the end of the array, for each value of the Signal. If the selector does not return a value, than the flag is ignored and no value is appended to the array.

Checklist

• [x] Updated CHANGELOG.md.

1. Methods would now be automatically implemented. Subclassing is no longer necessary.

2. DelegateProxy can now be constructed through NSObject.reactive.proxy(forKey:).

3. Fixed a memory leak due to the use of forwardingTarget(for:) as the fast path of delegate call forwarding.

4. More DelegateProxy test cases.

Usage

extension Reactive where Base: UITableView {
    var proxy: DelegateProxy<UITableViewDelegate> {
        return proxy(forKey: #keyPath(UITableView.delegate))
    }
}

To-do

• [x] Evaluate the behaviour of protocols with non-void-returning required methods.
• [x] Documentations and Implementation Notes.
• [x] Share implementation with method Interception.

Please note that this document is very much a work in progress. Some things that I've left to do:

• [ ] Remove the dependency on https://github.com/neilpa/Rex
• [ ] Produce an actual example project. (Much of the below code was typed "raw" into my text editor, and likely won't compile.)
• [ ] Get feedback from people who have been doing this much longer
• [ ] Fix the TODOs

There really isn't any sort of "canonical document" for creating UI code using ReactiveCocoa, and that's probably due to the fact that it's difficult to find a single approach or "recipe" that applies to all scenarios. In my own work on Capo and FuzzMeasure over the past 6 months I have found so many different scenarios and examples that forced me to repeatedly question what I was doing.

Just when I think that I have an approach figured out, I find another handful of new challenges when I move to another part of the UI to work on. For instance, when I built a lot of iOS UI code I found that it was very easy to build static UIs for UITableViewCells and use ViewModels to ensure that I encapsulate the presentation behavior.

Once I moved to editable controls for the Neptune UI I faced a whole new set of challenges when trying to get values propagated from my ViewModel down into my audio engine, and encapsulating a live-updating visualization (that wasn't needlessly updating the screen while playback wasn't active, also!)

I feel that this collection of "Recipes" for various UI patterns would be extremely helpful to people that are new to ReactiveCocoa, and folks that might be looking for ideas when discovering new challenges that they haven't faced before.