Comments (9)
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".
from reactiveswift.
I'm not sure why this wasn't included in the Swift APIs.
Where are you using it in your project?
from reactiveswift.
@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.
from reactiveswift.
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.
from reactiveswift.
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).
from reactiveswift.
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.
from reactiveswift.
@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.
from reactiveswift.
@andersio @NachoSoto Considering how old this is, might be time to close it?
from reactiveswift.
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. ๐
from reactiveswift.
Related Issues (20)
- Release 6.6.0 requires Swift 5.3 and therefore Xcode 12.x
- Using "<~" binding function with Signal.Observers causes memory leaks. HOT 3
- Using old xcconfig causing problems with Carthage & Apple Silicon macOS builds
- Support await / AsyncSequence HOT 13
- Playground does not work HOT 1
- Hello, ask a question about Disposable, thanks HOT 1
- What's means 'targeting' in QueueScheduler? HOT 2
- Signal.merge reported issue after migrating from ReactiveSwift from 4.0.0 -> 6.6.0 HOT 2
- xCode13 CompileSwiftSources normal x86_64 com.apple.xcode.tools.swift.compiler
- Usage with SwiftUI HOT 4
- Could not find module 'ReactiveSwift' for target 'arm64-apple-ios-simulator' HOT 2
- [BUG] XCode 14 beta 3 - bitcode issue HOT 1
- Is it planned to add count argument to `collect(every:on:skipEmpty:discardWhenCompleted:)`?
- Adopt OSAllocatedUnfairLock on iOS 16 HOT 9
- Add support for mapping Property/MutableProperty types to a Binding
- Signal triggered by phone call when device is closed HOT 3
- Infinite recursion in observeSwitchToLatest() HOT 3
- EXC_BAD_ACCESS Crashes occur in xcode15 HOT 4
- Reactive Swift crash with getCache function and observeSwitchToLatest signal
- Is there any plan for future releases? HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from reactiveswift.