As part of moving from RX to Combine. What exactly works like "BehaviorRelay" of RxRelay in Swift Combine?
As mentioned in this Cheat Sheet, an RxSwift BehaviorSubject is the same as the Combine CurrentValueSubject. A BehaviorRelay is a simple wrapper around a BehaviorSubject and could easily be recreated in Combine, but doesn't exist natively.
Related
This is maybe question more bout philosophy but for me important. Maybe one of you understand the source of this strange (at least for me) design. So in rxjs we have Observable and we have Subject. Subjects are in fact Observables on steroids but there are also extra features that you can add to Subject . You can use ReplySubject you can use AsyncSubject but you can't ReplyObservable. Is there any good reason for this? Of course you can go with operators, but api is still at least strange.
Subjects are both observables and observers. They're often the easiest way to transition from any imperative/object-oriented approach into functional/reactive streams (observables).
They're also one of the fairly standard ways to multicast a stream (Many of the multicasting operators actually use a subject internally to do their work).
Imperative to Reactive:
For example:
Ideologically, a BehaviorSubject represents a property. You can use its .next and .value as direct replacements for setting and getting a property's value. More importantly, however, you can react to changes in that value as though it were part of an observable stream (because Subjects are observables).
Why aren't there BehaviorObservables?
In some ways, this exists and in others, it doesn't. An observable can be given most of these behaviors with various operators.
const behaviourStream$ = stream$.pipe(
startWith(defaultValue),
shareReplay(1)
);
Every operator (at least pipeable) operator functions over Observables. They transform an observable from one type to another (often by implicitly manipulating the values within).
What properties an observable has depends on how it has been transformed. It's not often all that helpful to have specialized observables the same way it's helpful to have specialized Subjects.
Instead, observables have static operators that create new observables with certain built-in characteristics.
These are creation operators like interval, timer, from, etc
That is said. Subject has status, Observable don't, Observable is just like pure function, grab input, return output, end of story. Subject could store input one or other way, which makes it more rich and flexible
I've seen some discussion going on around using Observables instead of tasks with async/await. I currently make use of CreateFromTask almost exclusively. I've been trying to understand the reasoning behind using CreateFromObservable instead of CreateFromTask.
And if so, what would be the best way to convert a CreateFromTask to a CreateFromObservable.
CreateFromTask is really only there as a helper because we live in a predominantly Task based world :-) In a perfectly reactive world all the libraries you use would just expose Observables. Then you can just be end to end Observables. But seeing as how this isn't the case RxUI includes some helpers to easily pull Tasks into the Commands.
If you look here
https://github.com/reactiveui/ReactiveUI/issues/1245
You'll see there's even a discussion to just get rid of these helpers.
if you look at the code for "CreateFromTask" all it does is call ToObservble() on the task to convert it to an Observable and then the code calls CreateFromObservable
https://github.com/reactiveui/ReactiveUI/blob/develop/src/ReactiveUI/ReactiveCommand.cs#L418
So to that question I would just say calling ToObservable on the Task is the best way to convert it. You'll need to include this using statement
using System.Reactive.Threading.Tasks
What I normally do is just wrap all my Task based libraries with a facade and expose them using ToObervable. If you're going with a reactive solutions it will just make life easier to work in the land of Observables opposed to mixing and matching.
The reasoning behind CreateFromObservable over CreateFromTask is that the library assumes your solution is primarily reactive so that's going to be the primary way it is going to expect things. All the other ways to create those Commands are really just helpers that eventually make there way to CreateFromObservable
I have been reading apple documentation and I couldn't find an answer for this questions.
In the new variables we create in Swift should we be using some of the old NSClasses (like NSDictionary) or should we use the new Swift classes (like Dictionary).
I am trying to keep consistent in use Swift classes everywhere I can but is there any difference in between the two (in this case NSDictionary and Dictionary)
Did anyone find something about this topic in the apple documentation?
This is not a duplicate of "What is difference between NSDictionary vs Dictionary in Swift?"
I know the differences and I know that one has the root class NSObject and another has the root class AnyObject. Reformulating my question I want to know how that affect me as a developer? Did anyone did a benchmark? Is it fast slower? Is apple planning to make the NSClasses obsolete in the future? And I am not limiting this discussion to NSDictionary but to the whole new variables in swift that substitute the variables pre existents in Object-C
Swift classes provide type safety which means you assume less while working with objects inside collections. So it always better to use Swift variants than Objective-C wherever possible.
In swift, a lot of cocoa and framework constants have been put into namespaces. For example, NSCompositeSourceOver is now NSCompositingOperation.CompositeSourceOver.
This is generally a good thing. However, sometimes it's hard to work out where Apple have put certain constants. For example, I currently need kCGDesktopWindowLevel, and I can't find the damn thing. (There is kCGDesktopWindowLevelKey, but that's not the same thing.)
Is there a reference for this, or some set of files I can grep?
In the original CGWindowLevel.h, kCGDesktopWindowLevel is a macro defined to CGWindowLevelForKey(kCGDesktopWindowLevelKey). The macro was not imported, but the latter works fine in Swift as long as you add some type conversions: Int(CGWindowLevelForKey(CGWindowLevelKey(kCGDesktopWindowLevelKey))). (You might wish to file a bug since these type conversions are required.) You can see some of these things by ⌘-clicking on the CGWindowLevelForKey function, or using :print_module CoreGraphics from swift -integrated-repl.
How do I implement C# style signals or AS3 style events in Scala? I mean mostly observer pattern. To dispatch change events. Thanks.
Or (what's even better) are there any libraries/framework which do just that?
I'd suggest reading Deprecating the Observer Pattern first, for inspiration and to get a taste of where things are going.
Then, have a look at how scala-swing uses "reactions" to see how you can do this kind of thing in a library.
Finally, note that first-class functions make implementing the observer pattern yourself relatively easy.