Bring back the Subject?

[liscio]

A while ago, @andersio shared a gist with me that implemented a replacement for RACSubject. In essence, it just wraps the tuple returned by Signal<T,E>.pipe(), but works much nicer in practice.

Here's the gist containing his implementation: https://gist.github.com/andersio/3b4889176d6632bbb637ffd177795815/

Is there a reason that we don't offer this useful construct that we have available in ReactiveObjC? I've never loved the name, personally—calling it a Pipe would make far more sense—but since I integrated this code into a project I'm working on, life got a lot easier.

Thoughts?

[mdiep]

I'm not sure why this wasn't included in the Swift APIs.

Where are you using it in your project?

[liscio]

@mdiep At the moment I use it in places where I'd have used RACSubject in the past. For instance, I have a "view controller configuration" protocol that vends a SignalProducer<UIViewController,NSError> whenever a cell is selected.

It's not appropriate to store a mutable property containing SignalProducer<UIViewController,NSError>, but sending values to a Subject makes more sense. When the view controller is loaded/ready, it just sits and watches for that view controller to be pushed.

When this originally surfaced, @andersio and I were speaking about the common "table view cell configuration" pattern where we'd often just store properties containing the model values to be displayed, however we found that this might actually be a better solution—there's no additional storage required as the values are simply piped through to the destination UI components.

I don't use it in this way (yet), but it's on my list to investigate in the future as it seemed like a good idea to avoid building too many layers of storage.

Unit tests would be a lot nicer as well, because we use the pipe() pattern a lot there for testing.

The drawback of using an Observer (or Pipe) over the pipe() tuple is the ability to split the visibility of the two items. For instance, the observer could be made private, and the signal public.

[NachoSoto]

I don't think this is a good idea. I've seen this misused more often than not in RX frameworks.
The main reason being that IMO the same type shouldn't be used to represent both ends of the pipe, as it encourages users to expose too wide of a surface instead of only the "read only view".

[NachoSoto]

I'm pretty sure that was the reason for not making the pipe method return just one object, but two, because they almost always belong to different owners and they have different purposes.

[mdiep]

The main reason being that IMO the same type shouldn't be used to represent both ends of the pipe, as it encourages users to expose too wide of a surface instead of only the "read only view".

I definitely agree with this.

But that wouldn't preclude us from having a Pipe that conformed to ObserverProtocol and exposed a Signal (but didn't conform to SignalProtocol itself).

[liscio]

@NachoSoto

I've seen this misused more often than not in RX frameworks.

Could you elaborate a little bit on this misuse, and how we get around it in the current design?

This might help us to offer a path (and good explanation) to those that might wonder how to achieve what they did using RACSubject in the past.

[Qata]

@liscio We get around the misuse by decoupling the input and output into separate types. This allows us to model things in a cleaner way (a consumer that only needs to subscribe to the output can be passed solely the output, for example).
By changing the API to bring back Subject, we'd be recoupling the input/output and robbing ourselves of the control we have now.

[Qata]

@andersio @NachoSoto Considering how old this is, might be time to close it?

[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. 😄