Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
BehaviorRelay is a part of RxCocoa shouldn't it be a part of RxSwift? #1502
BehaviorRelay is a part of RxCocoa, shouldn't it be a part of RxSwift:
I was trying to access BehaviorRelay in my swift file, as I had already imported RxSwift. Could not access it and had no clue as to where to search for it. I finally realized that BehaviorRelay is a part of RxCocoa and not RxSwift
What actually happens:
How easy is to reproduce? (chances of successful reproduce after running the self contained code)
I have multiple versions of Xcode installed:
Level of RxSwift knowledge:
Hi @sandeeplearner ,
We will be moving
This is not a subject because it's not an observer.
Sorry am a noob in RxSwift. So did not really realize that it is a observer. I was confused by the statement that
Sorry forgive me for my dumb question, but don't you think RxCocoa should have Rx implementation for Cocoa components only and have non-cocoa and language specific components in RxSwift? At least name is little intuitive in that way.
For example, lets consider Foundation and UIKit frameworks,
That way figuring out where each component of programming lies becomes easy. Variable/BehaviorRelay can be used absolutely in isolation from UI components hence thought should be a part of RxSwift.
Just a thought :)
Hi @sandeeplearner ,
ideally, yes, I would agree with you. However there are some practical problems to consider:
... because we can't name those additional libraries in such a way that perfectly describes their content.
But I never say never.
Agree with sandeeplearner in that Variable was defined in RxSWift, and its replacement (if any) should also be in RxSwift.
Variable (and BehaviorRelay) are most definitely NOT UI components. Yes, you can bind them to UI components (and that binding could be in RxCocoa) but the concept can definitely be used anywhere in model and service-level code.
Further, I also take exception to simply moving Variable AND BehaviorRelay to RxCocoa. While we do import RxCocoa in our financial app, we only do so in the ViewControllers and other UI-based elements that need it.
Models, ViewModels, and Service files have all used Variable, and since they all know nothing about UI elements, those files import RxSwift ONLY. Why require modification of dozens upon dozens of source files to import yet another module that supports UI elements they shouldn't even know about?
The purest approach would be to extract relays into
I can understand the puristic approach, and separating concepts into their own self contained frameworks with small public API, but I would like to avoid creating, maintaining, importing and using two additional micro frameworks for puristic sake without any obvious benefits.
If I were to choose where to put relays, I would definitely pick RxCocoa for now because they are stateful convenience wrappers. They don't make any sense when using RxSwift in server side environment, they aren't cross platform and are just simple wrappers that one could recreate themselves if needed without even importing RxCocoa ... any yes, I understand what are the drawbacks of that approach and I'm not pretending there aren't any compromises.
Variables and Relays may not make any sense from a purist's perspective, but many people don't approach Rx in quite that fashion. Consider...
Here I have a set of tokens that I'm managing, while at the same time automatically exposing changes to that set to any observers who may be interested in those changes.
It's not Rx from the purist's perspective, but it's pretty good Swift. Note that I quite literally can not make any changes to my token list without that change being broadcast. The code's bulletproof. Add another function to remove a token, and the code's still bulletproof.
Not only do I have to maintain state separately, but I have to remember to explicitly fire the changed event for each and every operation. I had to write twice as much code, and it's more fragile than the original.
I could be more Rx'y, I suppose....
Which effectively provides the same functionality, albeit with more overhead, and with nearly 3x the code over the original version.
All of which boils down to three things:
I came to Swift to write less code. Not more.
No it's not. It's quite the opposite. If you call
Please give me benefit of the doubt that I understand this subject :)))
Sure, but you can always improve each of those ways somehow. I'm trying to tell you how should you use RxSwift, I'm trying to explain what is the rationale why some APIs are they way they are at the moment and also what are the tradeoffs of some other solutions we've considered.
The way to be constrictive about this discussion is to provide some new insights and tradeoffs of already considered scenarios or suggest new scenarios and enumerate their tradeoffs.
Again, I'm not sure you've read my answers carefully. This is still a stateful environment you are describing, so yes, there are user controls somewhere near there. Chances you could use that code in server side stateless environment is 0 IMHO.
I'm agreeing with the tautology.