[Feature] Microsoft.Toolkit.Mvvm package (Preview 4)

[Sergio0694]

Follow up to #3428

This PR is for tracking all changes/fixes/improvements to the Microsoft.Toolkit.Mvvm package following the Preview 3.

PR Type

What kind of change does this PR introduce?

• Feature
• Improvements

Overview

This PR is used to track and implement new features and tweaks for the Microsoft.Toolkit.Mvvm package.
See the linked issue for more info, and for a full list of changes included in this PR.

PR Checklist

Please check if your PR fulfills the following requirements:

• Tested code with current supported SDKs
• Pull Request has been submitted to the documentation repository instructions. Link:
• Sample in sample app has been added / updated (for bug fixes / features)
  • Icon has been created (if new sample) following the Thumbnail Style Guide and templates
• Tests for the changes have been added (for bug fixes / features) (if applicable)
• Header has been added to all new source files (run build/UpdateHeaders.bat)
• Contains NO breaking changes

[ghost]

Thanks Sergio0694 for opening a Pull Request! The reviewers will test the PR and highlight if there is any conflict or changes required. If the PR is approved we will proceed to merge the pull request 🙌

[sonnemaf]

Hi @Sergio0694,

I just noticed that the RelayCommand is a SEALED class. Why? I would love to derive from it. I would love to create something like a LabeledRelayCommand like this.

public class LabeledRelayCommand : RelayCommand, ILabeledCommand {

    public LabeledRelayCommand(Label label, Action execute) : this(label, execute, null) {
    }

    public LabeledRelayCommand(Label label, Action execute, Func<bool> canExecute) : base(execute, canExecute) {
        this.Label = label ?? throw new ArgumentNullException(nameof(label));
    }

    public Label Label { get; }
}

[Sergio0694]

Hey @sonnemaf - they're sealed because each command is not really meant to be extended in functionality, both due to how they're internally structured (eg. the AsyncRelayCommand with all the various fields and logic to handle cancellation etc.) and because we figured the main reason why devs would want to extend them would be, like in your case, just to add some extra properties that are unrelated to the actual commanding logic. In this case extending them would not really be ideal, especially because if you also wanted to have the same extra properties in other commands, you'd need to extend every single one of them and add the same property every time. For cases such as this I think the best approach is to use a type like StandardUICommand (from WinUI, here), which is meant to be used exactly in these situations. It has the advantage of having a number of extra properties built in, and it's meant to just bind to some ICommand, which means you can use it with all the 4 existing commands in the MVVM Toolkit without having to subclass any of them. Would this solve the issue in your situation? 😄

[sonnemaf]

@Sergio0694 Thank you for this explanation. This makes sense I will use the containment solution you suggested.

[Sergio0694]

Awesome, glad I could help! 😊

[ghost]

Hello @michael-hawker!

Because this pull request has the auto merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.