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

[Sergio0694]

Overview

This issue is meant to be used to track all the feature requests and discussions regarding API changes or other tweaks for the Microsoft.Toolkit.Mvvm package, which was introduced with #3230 and recently announced. 🎉

Find initial docs and samples here at https://aka.ms/mvvmtoolkit.

Key Tenants

• Platform and Runtime Independent - .NET Standard 2.0 🚀 (UI Framework Agnostic)
• Simple to pick-up and use - No strict requirements on Application structure or coding-paradigms (outside of 'MVVM'ness) i.e. flexible usage
• À la carte - Developer able to choose the components they wish to leverage
• Reference Implementation - Lean and performant, provides compliments to interfaces and paradigms hinted at in the Base-Class Library, but without provided implementations.

If you want more info on the package, you're welcome to browse our samples and preview documentation (here), watch the initial presentation by @michael-hawker and I (here) or watch Michael's presentation during the UNO Conf (here).

Tracking changes so far

Will be updating this list with all the current (work in progress) changes that are being included into a PR.

Preview 5 (#3562)

• Added ObservableValidator.ClearErrors method
• Added ObservableValidator.ValidateProperty method
• Added ObservableValidator.ValidateAllProperties method
• Added generic ObservableValidator.GetErrors method
• Speed/memory optimizations to WeakReferenceMessenger on .NET Standard 2.0

Preview 4 (#3527)

• Reintroduced Ioc class (see docs)
• Added new ObservableObject.OnPropertyChanged(PropertyChangedEventArgs) overload
• Added new ObservableObject.OnPropertyChanging(PropertyChangingEventArgs) overload
• The OnPropertyChanged and OnPropertyChanging overloads with a string param are no longer virtual
• Added notification support to IAsyncRelayCommand.CanBeCanceled property
• Improved notification logic for other IAsyncRelayCommand properties
• Added notification support to ObservableValidator.HasErrors property
• Added new TrySetProperty methods to ObservableValidator
• Minor performance/memory usage improvements and bug fixes

Preview 3 (shipped!) 🚀

ComponentModel, Input, DependencyInjection (#3429)

• New ObservableValidator class for INotifyDataErrorInfo
• Changed SetPropertyAndNotifyOnCompletion signature (7-14x faster, 60% memory usage reduction)
• Changed signature of APIs, ditched Expression<Func<T>> args
• Added new SetProperty<T, TModel> overload to allow stateless delegates and better performance
• Added cancelation support to AsyncRelayCommand types (and interfaces)
• Improved XML docs with info about exceptions being thrown by the various APIs
• Removed Ioc class and Microsoft.Extensions.DependencyInjection dependency

Messenger (#3424)

• Added a new WeakReferenceMessenger type
• Renamed Messenger to StrongReferenceMessenger
• Memory usage and performance improvements to StrongReferenceMessenger
• Changed IMessenger.Register signature to remove closures (35% memory usage reduction, no this captured)
• Added IMessenger.Cleanup API to help with extensibility
• Changed default messenger for ObservableRecipient to WeakReferenceMessenger

[Sergio0694]

Posting an update here regarding the changes to the SetPropertyAndNotifyOnCompletion method.
The signature now has a custom delegate instead of the ref + Expression<Func<T>> pair, which gives us:

• Less parameters (just one and with no duplication, so it's less error prone and verbose)
• Faster performance (no reflection anymore)
• Less memory usage

Code changes:

private Task myTask;

public Task MyTask
{
    // BEFORE
    set => SetPropertyAndNotifyOnCompletion(ref myTask, () => myTask, value);

    // AFTER
    set => SetPropertyAndNotifyOnCompletion(() => ref myTask, value);
}

And some benchmarks:

[Sergio0694]

Hey @nanney54, let's continue here from your original comment in the issue for the Preview1.

I've come up with a solution I liked to add cancellation support to the async commands, so this new feature should be available in the next preview of the MVVM Toolkit, and of course you can also try it out already through the CI preview build 😄

The changes were added in 06cc520, here's the new IAsyncRelayCommand interface:

/// <summary>
/// An interface expanding <see cref="IRelayCommand"/> to support asynchronous operations.
/// </summary>
public interface IAsyncRelayCommand : IRelayCommand, INotifyPropertyChanged
{
    /// <summary>
    /// Gets the last scheduled <see cref="Task"/>, if available.
    /// This property notifies a change when the <see cref="Task"/> completes.
    /// </summary>
    Task? ExecutionTask { get; }

    /// <summary>
    /// Gets a value indicating whether running operations for this command can be canceled.
    /// </summary>
    bool CanBeCanceled { get; }

    /// <summary>
    /// Gets a value indicating whether a cancelation request has been issued for the current operation.
    /// </summary>
    bool IsCancellationRequested { get; }

    /// <summary>
    /// Gets a value indicating whether the command currently has a pending operation being executed.
    /// </summary>
    bool IsRunning { get; }

    /// <summary>
    /// Provides a more specific version of <see cref="System.Windows.Input.ICommand.Execute"/>,
    /// also returning the <see cref="Task"/> representing the async operation being executed.
    /// </summary>
    /// <param name="parameter">The input parameter.</param>
    /// <returns>The <see cref="Task"/> representing the async operation being executed.</returns>
    Task ExecuteAsync(object? parameter);

    /// <summary>
    /// Communicates a request for cancelation.
    /// </summary>
    /// <remarks>
    /// If the underlying command is not running, or if it does not support cancelation, this method will perform no action.
    /// Note that even with a successful cancelation, the completion of the current operation might not be immediate.
    /// </remarks>
    void Cancel();
}

Both AsyncRelayCommand and AsyncRelayCommand<T> now include additional constructors taking a Func<CancellationToken, Task> delegate, so that you can also wrap asynchronous methods using the token parameter to monitor whether a cancellation has been requested. The commands will take of creating and handling those tokens, so you'll just need to use that Cancel method if you want to request a cancellation, and that request will be relayed to the wrapped method through that token. If you just wrap a method taking no token, the behavior is unchanged compared to commands today.

Here's a small example:

async Task<string> FooAsync(CancellationToken token)
{
    await Task.Delay(10000, token); // Delay with the token
    return "Hello world";
}

// Create a new async command wrapping the async method with
// the token parameter. The C# compiler will automatically pick the
// right constructor depending on the signature of the method we
// are using here (depending on whether it takes a token or not).
var command = new AsyncRelayCommand(FooAsync);

// Use the command as usual...

Let us know what you think! 😊

[nanney54]

It was fast ! did you have a git stash ready on your PC before my post ? 😁