Support for generating ICommands from methods

[PassivePicasso]

Before I knew this library was around I started developing my own version of it.
In investigating whether or not I should migrate, as this solution is much more mature than my implementation, I found that there is nothing responding to the need for building ICommands and DependencyProperties/StyledProperties (depending on WPF or Avalonia)

I am curious if Commands is something that would be considered for this library, or if you consider this something that would be a separate library.

I have support in my version of this solution for commands in the form of an AutoCommandAttribute which can take some parameters to handle CanExecute solution. It generates implementations of ICommand as nested classes for the generated type.

For reference this is my version of the Command implementation, I admit relative to this repo its much less rigorously designed.
My overall implementation is fairly barebones and likely has a lot of potential issues that I'm not aware of however it is here:
https://github.com/PassivePicasso/MVVMGenerator/blob/main/MVVMGenerator/Generators/AutoCommandGenerator.cs

Some aspects of note in my implementation;

• If a method is virtual, it is possible to override it in a derived class and use the Command generated by the base class to execute it as long as there are no new requirements.

• This is nice, however if the derived class needs to add a custom CanExecute, then there will be two nested Command classes with the same name, hiding the parent implementation without the new keyword. This could be officialized by adding the new keyword, but it doesn't feel like the best way to solve that problem.

• Nested classes are used to avoid conflicts.

• We auto-generate CanExecute for type validation by default, and add a check method when specified in the AutoCommandAttribute declaration

• Command classes are public to allow for usage outside the auto-generation, but this isn't necessarily a good setup for a general use library.

• Command fields and properties are exposed as ICommand, but its probably better to use the actual class instead of the interface for these properties.

Here is a sample of input/output

//User written class
public partial class TestViewModel 
{
    [AutoNotify]
    private bool isOpen;

    [AutoCommand]
    public void Test(int input) {}

    [AutoCommand(nameof(CanExecuteClose))]
    public void Close() => IsOpen = false;
    public bool CanExecuteClose() => IsOpen;
}

//Generated class
public partial class TestViewModel : INotifyPropertyChanged
{
    public class CloseCommandClass : ICommand
    {
        public event EventHandler CanExecuteChanged;
        readonly TestViewModel _owner;

        public CloseCommandClass(TestViewModel owner)
        {
                _owner = owner;
        }
        public bool CanExecute(object? parameter) 
        {
            return _owner.CanExecuteClose();
        }

        public void Execute(object? parameter)
        {
            _owner.Close(); 
        }
    }

    public class TestCommandClass : ICommand
    {
        public event EventHandler CanExecuteChanged;
        readonly TestViewModel _owner;

        public TestCommandClass(TestViewModel owner)
        {
                _owner = owner;
        }
        public bool CanExecute(object? parameter) 
        {
            return parameter is Int32;
        }

        public void Execute(object? parameter)
        {
            if(parameter is not Int32 typedParameter) return;
            _owner.Test(typedParameter); 
        }
    }

    private ICommand? closeCommand;
    private ICommand? testCommand;
    
    public ICommand CloseCommand => closeCommand ??= new CloseCommandClass(this);
    public ICommand TestCommand => testCommand ??= new TestCommandClass(this);

    public bool IsOpen
    {
        get => isOpen;
        set
        {
            isOpen = value;
            OnPropertyChanged();
        }
    }

    public event PropertyChangedEventHandler? PropertyChanged;
    void OnPropertyChanged([CallerMemberName] string? propertyName = null) 
    {
        PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
    }
}

[canton7]

I guess one major problem here is that System.Windows.Input.ICommand is WPF-specific, but PropertyChanged.SourceGenerator is not tied to any particular MVVM library or framework.

The MVVM toolkit has multiple variant packages for this reason, but that's not really a direction I want to go down with this library.

[PassivePicasso]

I don't beleive this is the case, everything is built off of System.Windows.Input.ICommand whether Avalonia's ReactiveCommand or the common WPF RelayCommand implementations, ActionCommand, etc., MAUI utilizes it as well.

UWP has a copy of ICommand, in its own namespaces, but its the same shape.
However, UWP is also compatible with System.Windows.Input.ICommand.

I tried to investigate the variant packages you mentioned, but I was unable to locate them.
Wanting to avoid having multiple variant packages is something I can absolutely agree with, as it would damage the simplicity of the consumer experience.

I think a pertinent question is if there are important implementation details that should be handled differently in these frameworks.
If the answer is no, then the simple implementations in the examples should work across environments successfully.

I can confirm this was used successfully in a WPF and Avalonia project. It was part of its initial development.
https://github.com/PassivePicasso/GodotLauncher/tree/avalonia

This uses a much older version of my generators, it was where they were first developed, and were used across a WPF and Avalonia front end specifically for exploring the portability potential.
I had total forgot that I had done this, but it proves out the foundation.