[API Proposal]: ICommand.Null

[terrajobst]

Background and motivation

For abstractions like ICommand it's useful to have a standard implementation that does nothing. We have some of them already, such as Stream.Null and TextWriter.Null.

API Proposal

namespace System.Windows.Input;

public partial interface ICommand
{
    public static ICommand Null { get; } = new NullCommand();

    private sealed class NullCommand : ICommand
    {
        public event EventHandler? CanExecuteChanged
        {
            add {}
            remove {}
        }
    
        public bool CanExecute(object? parameter)
        {
            return true;
        }
    
        public void Execute(object? parameter)
        {
            // Do nothing
        }
    }
}

API Usage

private ICommand _command = ICommand.Null; // Might be set to something meaningful later

Alternative Designs

We could put it on a class instead, but we don't have a built-in implementation of ICommand in System.ObjectModel.dll, so I don't believe there is a good candidate. We could, of course, create one.

Risks

No response

[colejohnson66]

What about NullCommand.Instance? I personally don’t like the look of static properties on instances.

[Sergio0694]

Small note to consider: this will break with trimming/AOT when using CsWinRT. The experience won't be great because right now, this would produce no warnings, but it will just crash at runtime (because ICommand.Null wouldn't have CCW vtable information on it). If we do want to add an API like this, it might be a good idea to also consider support in CsWinRT as part of the design to make sure that using it would work as expected on NativeAOT. cc. @manodasanW

Side note, in the long run, this would also tie into CsWinRT using extension interfaces to provide CCW descriptions.

[terrajobst]

@Sergio0694

Breaking the WinRT projections would certainly be a good argument for avoiding a static interface member.

@colejohnson66's argument ("I don't like what it looks like") isn't good enough for me. Partially because I think that's just the nature of a new feature (it looks foreign because it's new) and partially because we know from UX studies that types add more concept count which members generally do not (except for special cases like IEnumerable<T> extension methods showing up elsewhere).

The primary reason for using statics here is because we don't ship a default implementation in the base layer, which might be worth changing.

[KalleOlaviNiemitalo]

System.IO.Stream.Null has each of CanRead, CanWrite, and CanSeek returning true; but implements methods as no-ops.
Microsoft.Extensions.Logging.Abstractions.NullLogger has IsEnabled(LogLevel) returning false, and implements BeginScope and Log<TState> as no-ops.

In this respect, it is surprising that NullCommand.Execute(object?) would throw InvalidOperationException. Is there any precedent for "Null" implementations doing so?

[terrajobst]

That's a fair question.

The way I think about this:

• System.IO.Stream.Null is meant as a stream you can pass to anyone without anything bad happening. That means you can read/write but you don't get data. It's odd that it supports seeking, but hey.

• Is a dummy command a command that is disabled or a command that is enabled but does nothing? I don't care too much either way, but I can buy that enabled with no-op is more natural.

[colejohnson66]

My $0.02: When writing the view for a UI, I like buttons to appear normally, but do nothing. However, in Avalonia, if the command in bound command can’t execute, the button acts disabled (style- and interaction-wise). So, when writing the skeleton view model, I have to use a “dummy command” the can execute, but does nothing. I personally would expect a “null” command to do the same.

Alternatively, two could be provided: one that can execute (but does nothing), and one that can’t (but throws).

[terrajobst]

When writing the view for a UI, I like buttons to appear normally, but do nothing.

That makes sense to me. I'll update the proposal accordingly.

[Sergio0694]

"For abstractions like ICommand it's useful to have a standard implementation that does nothing."

Perhaps we should include some examples? The issue just says "it's useful", but I personally can't think of a single time I've ever used something like this in any apps I've ever made or worked on or saw the source code for, nor can I really think of a scenario where I'd imagine myself needing this either, to be completely honest 😅