Keeping external models out of your reducer

[tylerjames]

I have an app that connects to a remote video feed over WebRTC.
I've managed to move most of the connection handling code out into a Client that exists outside my feature but there is one area where I'm having trouble keeping one of these WebRTC-related classes out of my reducer.

There's a lot of initial activity that my feature client needs to do to set up the connection and a few other clients it needs to interact with (WebRTC, SignalingClient, Kinesis) and once the connection is established I need to provide the WebRTC client with a view that the video will be rendered into. The type of this view is RTCVideoRenderer.

Right now I'm observing a connectionReady property on my state and then sending this RTCVideoRenderer in an action .renderInto(RTCVideoRenderer). This feels really gross to do. It feels like my reducer shouldn't have anything to do with this RTCVideoRenderer class but I don't really know how I should be bridging this gap between my external WebRTC client and my view that needs to render the video.

Any one have any ideas about how to handle this type of situation?

[tylerjames]

Hmm, maybe all the WebRTC talk made this question not general enough.

I suppose more generally the problem would be when you have a client that requires some direct interaction with your view layer. In this case my view layer needs to pass an instance of a UIView subclass that the client uses. Maybe it's permissible to pass this UIView subclass to my client by invoking an Action on my Reducer but it feels wrong to have this weird class in my Reducer.

Maybe I'm just worrying too much about it though.

[mbrandonw]

You can certainly usher a 3rd party class from the view to the client via an action, but the big question is how does it hurt testability. First of all, your action will most likely no longer automatically conform to Equatable, and you will not be able to assert against that data in tests.

What you can do instead is cook up a simple struct representation of the 3rd party class that holds a field for each property in the class. And that struct can be initialized with the 3rd party class.

We have some examples of this in various demos, such as the speech recognition demo and even in the composable-core-location library.

We also discussed this in episode 157, and here's a direct link. In that episode we needed to store a MKLocalSearchCompletion in state, but wanted to do so in a testable way. So we had to make a wrapper type for it.

[tylerjames]

Yeah it seemed distasteful to me for sure.

Thanks, I'll take a look at the examples. These WebRTC libraries are a bit cumbersome to work with at times (most times). If it used some more general underlying type that I could forward through that would be handy but it's an Objective-C library with a thin Swift interface that uses custom RTC classes

[Sajjon]

I have an app that connects to a remote video feed over WebRTC.

I've managed to move most of the connection handling code out into a Client that exists outside my feature but there is one area where I'm having trouble keeping one of these WebRTC-related classes out of my reducer.

There's a lot of initial activity that my feature client needs to do to set up the connection and a few other clients it needs to interact with (WebRTC, SignalingClient, Kinesis) and once the connection is established I need to provide the WebRTC client with a view that the video will be rendered into. The type of this view is RTCVideoRenderer.

Right now I'm observing a connectionReady property on my state and then sending this RTCVideoRenderer in an action .renderInto(RTCVideoRenderer). This feels really gross to do. It feels like my reducer shouldn't have anything to do with this RTCVideoRenderer class but I don't really know how I should be bridging this gap between my external WebRTC client and my view that needs to render the video.

Any one have any ideas about how to handle this type of situation?

Is your WebRTC code open source? I used Stasels binaries and bridged to structurally concurrency. Might benefit us both to share code, cannot share now but later.