CODEWITHSUNDEEP
swiftmvvmrx-swift
Nikita Vlasenko
Nikita Vlasenko

Reputation: 4352

RxSwift, why using .never() not for testing

I am going through the tutorial:

https://marcosantadev.com/mvvmc-with-swift/

Which talks about MVVM-C design pattern. I have real trouble understanding of how and why .never() observable is used there (and in general why we would want to use .never() besides testing timeouts).

Could anyone give a reasonable example of .never() observable usage in swift code (not in testing) and explain why it is necessary and what are the alternatives?

Upvotes: 0

Views: 716

Answers (3)

Chris Conover
Chris Conover

Reputation: 9039

It's an open ended question, and there can be many answers, but I've found myself reaching for never on a number of cases. There are many ways to solve a problem, but recently, I was simplifying some device connection code that had a cascading fail over, and I wanted to determine if my last attempt to scan for devices yielded any results.

To do that, I wanted to create an observable that only emitted a "no scan results" event in the event that it was disposed without having seen any results, and conversely, emitted nothing if it did.

I have pruned out other details from my code to sake of brevity, but in essence:

func connect(scanDuration: TimeInterval) -> Observable<ConnectionEvent> {
    let scan = scan(for: scanDuration).share(replay: 1)
    let connection: Observable<ConnectionEvent> =
        Observable.concat(Observable.from(restorables ?? []),
                          connectedPeripherals(),
                          scan)
        .flatMapLatest { [retainedSelf = self] in retainedSelf.connect(to: $0) }
    
    let scanDetector = scan
        .toArray()  // <-- sum all results as an array for final count
        .asObservable()
        .flatMap { results -> Observable<ConnectionEvent> in
            results.isEmpty // if no scan results
                ? Observable.just(.noDevicesAvailable) // emit event
                : Observable.never() } // else, got results, no action needed

    // fold source and stream detector into common observable
    return Observable.from([
        connection
            .filter { $0.isConnected }
            .flatMapLatest { [retained = self] event -> Observable<ConnectionEvent> in
                retained.didDisconnect(peripheral: event.connectedPeripheral!.peripheral)
                    .startWith(event) },
        scanDetector])
        .switchLatest()
}

For a counter point, I realized as I typed this up, that there is still a simpler way to achieve my needs, and that is to add a final error emitting observable into my concat, it fails-over until it hits the final error case, so I don't need the later error detection stream.

        Observable.concat(Observable.from(restorables ?? []),
                      connectedPeripherals(),
                      scan,
                      hardFailureEmitNoScanResults())

That said, there are many cases where we may want to listen and filter down stream, where the concat technique is not available.

Upvotes: 0

iWheelBuy
iWheelBuy

Reputation: 5679

I address all the actions from View to ViewModel. User taps on a button? Good, the signal is delivered to a ViewModel. That is why I have multiple input observables in ViewModel. And all the observables are optional. They are optional because sometimes I write tests and don't really want to provide all the fake observables to test some single function. So, I provide other observables as nil. But working with nil is not very convenient, so I provide some default behavior for all the optional observables like this:

private extension ViewModel {

    func observableNavigation() -> Observable<Navigation.Button> {
        return viewOutputFactory().observableNavigation ?? Observable.never()
    }

    func observableViewState() -> Observable<ViewState> {
        return viewOutputFactory().observableViewState ?? Observable.just(.didAppear)
    }
}

As you can see, if I pass nil for observableViewState I substitute it with just(.didAppear) because the ViewModel logic heavily depends on the state of view. On the other hand if I pass nil for observableNavigation I provide never() because I assume that non of the navigation button will ever be triggered.

But this whole story is just my point of view. I bet you will find your own place to use this never operator.

Upvotes: 1

Julien Perrenoud
Julien Perrenoud

Reputation: 1571

Maybe your ViewModel has different configurations (or you have different viewModel under the same protocol), one of which does not need to send any updates to its observers. Instead of saying that the observable does not exist for this particular case (which you would implement as an optional), you might want to be able to define an observable as a .never(). This is in my opinion cleaner.

Disclaimer - I am not a user of RxSwift, but I am assuming never is similar than in ReactiveSwift, i.e. a signal that never sends any value.

Upvotes: 1

Related Questions