One very exciting possibility of a source-generated mediator implementation is to ease the pain of tracking down what methods are called by the mediator, at design time. At runtime, step-through debugging makes this a breeze, but at design-time you must parse the generated code and follow a few steps in order to find the handler code, which is not something I want to force on my fellow developers.
Does the source generator know enough context to include an xml comment linking to the handler method? An example of this is the MVVM Community Toolkit source generators for RelayCommands, which generate the following
/// <summary>Gets an <see cref="global::CommunityToolkit.Mvvm.Input.IAsyncRelayCommand"/> instance wrapping <see cref="Initialize"/>.</summary>
public global::CommunityToolkit.Mvvm.Input.IAsyncRelayCommand InitializeCommand => initializeCommand ??= new global::CommunityToolkit.Mvvm.Input.AsyncRelayCommand(new global::System.Func<global::System.Threading.Tasks.Task>(Initialize));
This pattern has helped immensely to decouple our code, but it would be nice to have our cake and eat it to - the analyzers for unhandled messages and command are another huge usability bump!
One very exciting possibility of a source-generated mediator implementation is to ease the pain of tracking down what methods are called by the mediator, at design time. At runtime, step-through debugging makes this a breeze, but at design-time you must parse the generated code and follow a few steps in order to find the handler code, which is not something I want to force on my fellow developers.
Does the source generator know enough context to include an xml comment linking to the handler method? An example of this is the MVVM Community Toolkit source generators for RelayCommands, which generate the following