Add interop with Apple's Combine framework

[mdiep]

As far as I'm aware, Apple hasn't addressed whether Combine will (a) be open source or (b) be cross-platform. So even beyond the current apps that use and depend on ReactiveSwift, I don't think ReactiveSwift is going anywhere for the time being.

But we should build an interop layer for converting between ReactiveSwift and Combine. This should be helpful for apps that want to transition from one library to the other. But it should also help for using SwiftUI from apps that currently use ReactiveSwift.

[swizzlr]

I'm looking into implementing a compatibility layer so that Combine can run on iOS 12 using ReactiveSwift as the underlying framework. Is this similar to what you're proposing, or more for just something that can wrap Combine types in ReactiveSwift types and vice versa?

[mdiep]

I was suggesting something that bridges the types—similar to ReactiveObjCBridge.

[gkaimakas]

Sounds like an awesome idea! Any updates on this?

[simba909]

Over the weekend I spent some time to throw together a quick implementation of this, which can be found here: https://github.com/simba909/ReactiveCombineBridge

Please note that this needs (probably a lot..) more work, but in my quick testing it seems to work for the most common use cases:

• Converting a Publisher to a SignalProducer
• Converting a Signal/SignalProducer to a Publisher

Feedback/issues/PRs are more than welcome, and if there's interest in the long run to bring this work over to ReactiveCocoa I'd be more than happy to migrate it 👍

[andersio]

we should build an interop layer for converting between ReactiveSwift and Combine.

Since Combine ships as a system framework not requiring entitlements, the interoperability layer can be integrated directly in the ReactiveSwift library (provided that weak linkage in Swift works as expected).

My rough plan is:

1. Introduce explicit conversions akin to ReactiveObjcBridge.
   in-progress Combine Interoperability: first iteration #776

2. Extend all FRP operators and bindings accepting SignalProducerConvertible to accept also Publisher, so publishers can be used in e.g. flatMap and <~.

   Since Swift does not support conditional conformances via protocol extensions, this would translate into more overloads.

3. Introduce RAS counterparts to @Published and ObservableObject.
   While not being essential to the bridging experience, it enables the same pattern for RAS users, and provide default implementation for ObservableObject for indirect SwiftUI interoperability.

   (This requires use of a unsupported compiler feature that backs @Published to apply a AnyObject constraints to the containing type)

[vctrch]

Any updates on this? Would love to see this happen.

[lukaskubanek]

I’d also like to ask whether there are plans to add a Combine bridge in the foreseeable future. Or should I rather build the necessary pieces for the purpose of my app myself?

[RuiAAPeres]

Hello. 👋 Thanks for opening this issue. Due to inactivity, we will soft close the issue. If you feel that it should remain open, please let us know. 😄