Proposal: Serial Reactive Commands

[kentcb]

One scenario that is far harder to achieve than it should be is a serial command. That is, a command that can be executed even if already executing, but latter executions automatically cancel outstanding executions. One example of where this is useful is in user-instigated searches. An existing search may be in progress, but the user may modify their query and trigger another search before the previous one completes. In such cases, the previous search operation should be null and void, supplanted by the new.

Whilst there are ways to model this using ReactiveUI today, they are both cumbersome and limited. One can create two commands - one to do the real work, and another to manage the cancellation of outstanding work before invoking the real work. It's not intuitive. Moreover, InvokeCommand always respects CanExecute. Since the command may already be executing, this means you can't use InvokeCommand to trigger executions. You instead have to call Execute yourself (which bypasses the CanExecute check). Whilst we could instead change InvokeCommand to permit ignoring CanExecute, this only side-steps the smaller part of the problem - it doesn't help with the implementation of cancellation semantics.

My current thinking for resolving this is to introduce ReactiveCommand.CreateSerialFromObservable and ReactiveCommand.CreateSerialFromTask factory methods, which create instances of a new SerialReactiveCommand class on behalf of the caller. The SerialReactiveCommand class would contain the smarts for ensuring it is always executable, and that latter executions supersede any former ones.

Feedback welcome.

[bradphelan]

We do this kind of thing all the time in our app. The standard way to have a stream of events that supersede the previous command is.

source
  .Select(value => Observable.FromAsync( ct => Task.Run(()=> SlowAction(ct),ct)).Switch(); 

Where ct is cancellation token that get's triggered every time the IObservable is disconnected. ( via the Switch )

I would personally create a method SelectAsync combinator

public static IObservable<U>
SelectAsync<T>(this IObservable source, Func<T,CancellationToken,U> fn)

that wraps the above. However exceptions thrown in the fn will terminate the observable subscription which is annoying. We use IObservableExceptional to get around that

https://github.com/Weingartner/Exceptional

which treats errors as data rather than something that terminates the subscription. For reactiveui this is a better model.

However in this case source would be a subject driven by the command.

var source = new Subject<Unit>();
var command = ReactiveCommand.Create(()=>source.OnNext(Unit.Default))

As the command body returns after calling OnNext CanExecute will almost always
be true.

Originally in RxUI ReactiveCommand itself was IObservable which made the pattern easier to work with. ReactiveCommand could then be ( using IObservableExceptional ) For example using IObservableExceptional

    command = ReactiveCommand
            .Create(canExecute)
            .SelectAsync((unit,ct)=>SlowTask(ct))
            .Subscribe(onNext:v=>Console.WriteLine(v),
                       onError:err=>Console.WriteLine(err));

on event of error the command will not be disconnected. It is more general than the current solution for ReactiveCommand and error handling.

[bawkee]

I ended up writing a SerialReactiveCommand class for this as I have all the exact same problems Kent described. Here's the gist, it should have all the same traits as a plain old ReactiveCommand except:

• There is no 'double-tap' guard (for obvious reasons), so the CanExecute will not tick false while executing by default.
• Invoking another execution while the command is executing will first cancel the previous one, wait for cancellation to complete and then tick the next execution.
• There is a built-in Cancel observable in the command object.

I have used this in my code but haven't yet made any unit tests. It comes as close to regular command as possible, the only difference is that it will (well, should) automatically handle all the nuances that come with this requirement.

I found myself needing this more often than not so it removed quite a lot of boilerplate so far and made the code a lot more readable.

Hope it helps, cheers!

[glennawatson]

@bawkee thanks will check it out. If you want to make a PR to get the release note credit feel free also.

[Herz3h]

@bradphelan I'm trying to achieve same thing as OP, but I can't figure it out. (have search command cancel all previous search commands)

I have a SearchCommand and another CancelSearchCommand, but it seems that using trying to cancel the search command before executing a new search (calling CancelSearchCommand at the beginning of SearchCommand) stops all search command from working altogether.

Could you give an example of how to achieve this please ?