RelayCommand: CanExecute no longer automatically checked on Execute

[RedX2501]

I'm migrating from MvvmLight to MVVM Toolkit.

I was wondering what the explanation is for not automatically calling CanExecute on every Execute invocation?

In MvvmLight this was the case but as indicated by the test Test_RelayCommand_WithCanExecuteFunctionFalse this seems to no longer be a desired functionality.

I was wondering why this change. What was considering when not taking over such a "obvious" behaviour?

Further why is this not mentioned in the Migration Guide?

[Sergio0694]

We decided not to do this as it was technically against the ICommand interface (see here). The docs for Execute say that that method will execute the command action, they don't mention anything about it doing the "can execute" checks again. It's whoever's using the command that's responsible for calling CanExecute first, or it's the UI framework binding to the command that's responsible for subscribing to CanExecuteChanged and then calling CanExecute to update the IsEnabled state for whatever button or control is bound to the command. This is also what the command implementation from WPF is doing. What was in MvvmLight was not really following the ICommand contract, so we rectified that in the MVVM Toolkit. Note that on most UI frameworks (eg. UWP and WinUI, but also MAUI), if you eg. have a button binding to a command, the button will automatically be disabled when the command cannot be executed, so you already cannot invoke it anyway in that cases. There's no point in having Execute do those checks again when you actually do click on the command.

We should mention that in the docs too, absolutely. We just haven't had time to update them just yet 🙂

[RoarkDude]

There's no point is using CanExecute if it doesn't automatically fire the datasource changes, right?

[RedX2501]

I agree with you on all the points.

Yet I'd like to point out that the documentation of ICommand does not state that CanExecute must be called before calling Execute. It only says it CanExecute CAN be used to determine if it's in an executable state.

You are therefore relying on an implementation detail to justify this change. I do understand that no current (and probably future framework) will ever deviate from this.

That's why I'd like to know whether there would be an interest in a CheckedRelayCommand implementation? It would check CanExecute before invoking Execute. This would avoid the same boilerplate code in user projects that call RelayCommands.

Another benefit is that we could have a version that only passes non-nullable values to Execute.

[Arlodotexe]

If you aren't using the source generators, you can create your own CheckedRelayCommand and CheckedAsyncRelayCommand by implementing the IRelayCommand and IAsyncRelayCommand interfaces respectively.

[RedX2501]

I'm sorry to pick this up but I have seen something strange. The disassembly of the source code with VS showed me this:

Please notice that it is a very recent release and yet the Execute does a CanExecute check. Do I have some other nuget? Are there multiple nugets wtih the same name out? Is the decompiler simply wrong?

#region Assembly Microsoft.Toolkit.Mvvm, Version=7.1.0.0, Culture=neutral, PublicKeyToken=4aff67a105548ee2
// C:\data\Silt4\src\App\Packages\microsoft.toolkit.mvvm\7.1.2\lib\netstandard2.0\Microsoft.Toolkit.Mvvm.dll
// Decompiled with ICSharpCode.Decompiler 6.1.0.5902
#endregion

using System;
using System.Runtime.CompilerServices;
using System.Windows.Input;

namespace Microsoft.Toolkit.Mvvm.Input
{
    //
    // Summary:
    //     A command whose sole purpose is to relay its functionality to other objects by
    //     invoking delegates. The default return value for the Microsoft.Toolkit.Mvvm.Input.RelayCommand.CanExecute(System.Object)
    //     method is true. This type does not allow you to accept command parameters in
    //     the Microsoft.Toolkit.Mvvm.Input.RelayCommand.Execute(System.Object) and Microsoft.Toolkit.Mvvm.Input.RelayCommand.CanExecute(System.Object)
    //     callback methods.
    public sealed class RelayCommand : IRelayCommand, ICommand
    {
        //
        // Summary:
        //     The System.Action to invoke when Microsoft.Toolkit.Mvvm.Input.RelayCommand.Execute(System.Object)
        //     is used.
        private readonly Action execute;

        //
        // Summary:
        //     The optional action to invoke when Microsoft.Toolkit.Mvvm.Input.RelayCommand.CanExecute(System.Object)
        //     is used.
        private readonly Func<bool>? canExecute;

        public event EventHandler? CanExecuteChanged;

        //
        // Summary:
        //     Initializes a new instance of the Microsoft.Toolkit.Mvvm.Input.RelayCommand class
        //     that can always execute.
        //
        // Parameters:
        //   execute:
        //     The execution logic.
        [NullableContext(1)]
        public RelayCommand(Action execute)
        {
            this.execute = execute;
        }

        //
        // Summary:
        //     Initializes a new instance of the Microsoft.Toolkit.Mvvm.Input.RelayCommand class.
        //
        // Parameters:
        //   execute:
        //     The execution logic.
        //
        //   canExecute:
        //     The execution status logic.
        [NullableContext(1)]
        public RelayCommand(Action execute, Func<bool> canExecute)
        {
            this.execute = execute;
            this.canExecute = canExecute;
        }

        //
        // Summary:
        //     Notifies that the System.Windows.Input.ICommand.CanExecute(System.Object) property
        //     has changed.
        public void NotifyCanExecuteChanged()
        {
            this.CanExecuteChanged?.Invoke(this, EventArgs.Empty);
        }

        [MethodImpl(MethodImplOptions.AggressiveInlining)]
        public bool CanExecute(object? parameter)
        {
            return canExecute?.Invoke() ?? true;
        }

        public void Execute(object? parameter)
        {
            if (CanExecute(parameter))
            {
                execute();
            }
        }
    }
}

// Rest omitted.

[StephanZilke]

I think, you have to use version 8.0.0-preview to use the source generators.

[RedX2501]

I might be a bit confused but how dose this disassembly relate to source generators?

If you mean the generators for example for [ObservableProperty] I can already use them._

[Sergio0694]

The disassembler opened version 7.1.2, so you're looking at the wrong code. Check the first line of the disassembled file 🙂

[RedX2501]

@Sergio0694 That's exactly what I'm curious about. I understood that it was never implemented with Execute calling CanExecute before.

This means that it's only from 8.0 onwards that this will be removed?

[Sergio0694]

Correct, the change was made sometimes after 8.0.0-Preview2. The 7.x.x branch is dead and will no longer receive updates 🙂