Piping data from delegate methods of external dependency back into the reducer

[tylerjames]

My app has a video streaming feature that works over WebRTC and lets me view the video stream of a remote camera.

The connection process is somewhat complex and I want to keep this hidden from my feature. When I first wrote it my view controller held a reference to the WebRTCClient and set itself as a delegate but I'd like to refactor this into a clean TCA feature.

This is mostly straightforward, but the entire time that the connection is active there are a few delegate methods that could be called at any time and could produce some relevant results for my feature.

How do I handle this delegate situation for a long-lived delegate that could produce multiple results at any time?

My wrapper client which holds my WebRTCClient exposes a simple connect(_ hostUrl:String) method to initiate the connection. Do I somehow need to funnel all the delegate activity into an async sequence that is returned by this connect method?

[JacksonUtsch]

My lazy POV is to stay away from async sequences for dealing with long-lived effects until it is fleshed out more. I'm sticking to Combine with PassthroughSubject and CurrentValueSubject for these situations.

[tylerjames]

Hmm. I suppose that makes sense. Shame that the async stuff isn't ready to handle this situation but it did certainly have a Combine-y feel to it.

[gohanlon]

I recently started using AsyncStream in my project. Still, sticking with Combine seems perfectly reasonable.

I found Isowords's use of AsyncStream helpful (e.g. ComposableGameCenter.GameCenterViewControllerClient.live). I also put together an illustrative use of AsyncStream to emit values over time, where each value needs to be delivered to every subscriber.

[tylerjames]

Thanks, that's very helpful. I don't have much experience with async streams (sounds like most people don't) so it's instructive to see an example in a familiar setting.

tbh it (async streams) feels a bit awkward. Reminds me of implementing observer pattern in Java where you hold on to references of all your observers and then loop through and notify them any time something changes.

[gohanlon]

Indeed. This is mainly due to Swift's structured concurrency APIs being lower level than the Combine operators you'd typically use. In time, Swift Async Algorithms intends to provide Cobine-like operators using structured concurrency. Today, that's a work in progress and lacks many commonly needed operations. If Async Algorithms had a multicast operator, the above example could be as trivial as the Combine approach but with the advantages of structured concurrency.

I'm not aggressively removing Combine just yet. But, I am eliminating Combine uses that are covered by Swift's structured concurrency APIs or Async Algorithms and am gradually reimplementing the specific Combine operations I need.

[tylerjames]

That'll be nice when they get the Async Algorithms stuff sorted then. It's funny I've been writing reactive code (mostly RxSwift) for a couple years now and I'd forgotten how nice it is to just write the code in a straight line and not have to futz about with .flatMap and merging or combining different streams together.