Extension methods to cleanly register Views and ViewModels in IServiceCollection

[rjygraham]

I'd like to propose adding the following extension methods to CommunityToolkit.Maui which cleanly registers Views and ViewModels in the MAUI IServiceCollection. I've also added extension methods to optionally register Shell routes for pages not explicitly added to AppShell.xaml:

using System.ComponentModel;

namespace CommunityToolkit.Maui.Extensions;

public static class ServiceCollectionExtensions
{
	public static IServiceCollection AddSingletonPage<TView, TViewModel>(this IServiceCollection serviceCollection)
		where TView : Page
		where TViewModel : class, INotifyPropertyChanged
	{
		serviceCollection.AddSingleton<TViewModel>();
		serviceCollection.AddSingleton<TView>();
		
		return serviceCollection;
	}

	public static IServiceCollection AddSingletonPageWithRoute<TView, TViewModel>(this IServiceCollection serviceCollection)
		where TView : Page
		where TViewModel : class, INotifyPropertyChanged
	{
		serviceCollection.AddSingletonPageWithRoute<TView, TViewModel>(typeof(TView).Name);

		return serviceCollection;
	}

	public static IServiceCollection AddSingletonPageWithRoute<TView, TViewModel>(this IServiceCollection serviceCollection, string route)
		where TView : Page
		where TViewModel : class, INotifyPropertyChanged
	{
		Routing.RegisterRoute(route, typeof(TView));
		serviceCollection.AddSingletonPage<TView, TViewModel>();

		return serviceCollection;
	}

	public static IServiceCollection AddTransientPage<TView, TViewModel>(this IServiceCollection serviceCollection)
		where TView : Page
		where TViewModel : class, INotifyPropertyChanged
	{
		serviceCollection.AddTransient<TViewModel>();
		serviceCollection.AddTransient<TView>();
		
		return serviceCollection;
	}

	public static IServiceCollection AddTransientPageWithRoute<TView, TViewModel>(this IServiceCollection serviceCollection)
		where TView : Page
		where TViewModel : class, INotifyPropertyChanged
	{
		serviceCollection.AddTransientPageWithRoute<TView, TViewModel>(typeof(TView).Name);
		
		return serviceCollection;
	}

	public static IServiceCollection AddTransientPageWithRoute<TView, TViewModel>(this IServiceCollection serviceCollection, string route)
		where TView : Page
		where TViewModel : class, INotifyPropertyChanged
	{
		Routing.RegisterRoute(route, typeof(TView));
		serviceCollection.AddTransientPage<TView, TViewModel>();

		return serviceCollection;
	}
}

Below is an example of the extension methods in use:

using CommunityToolkit.Maui.Extensions;

namespace MauiApp1

public static class MauiProgram
{
	public static MauiApp CreateMauiApp()
	{
		var builder = MauiApp.CreateBuilder();
		builder
			.UseMauiApp<App>()
			.UseMauiCommunityToolkit()
			.ConfigureFonts(fonts =>
			{
				fonts.AddFont("OpenSans-Regular.ttf", "OpenSansRegular");
				fonts.AddFont("OpenSans-Semibold.ttf", "OpenSansSemibold");
			})
			.AddSingletonPage<AppShell, AppShellViewModel>()
			.AddSingletonPage<HomePage, HomePageViewModel>() // Singleton View/ViewModel explicitly added to AppShell.xaml with Route specified there
			.AddTransientPage<SettingsPage, SettingsPageViewModel>() // Transient View/ViewModel explicitly added to AppShell.xaml with Route specified there
			.AddTransientPageWithRoute<LoginPage, LoginPageViewModel>() // Transient View/ViewModel which registers route via Routing.RegisterRoute with routeName = nameof(LoginPage)
			.AddTransientPageWithRoute<AnotherPage, AnotherPageViewModel>("SpecialRoute") // Transient View/ViewModel which registers route via Routing.RegisterRoute with routeName = "SpecialRoute"
			.AddSingletonPageWithRoute<SignupPage, SignupPageViewModel>("Signup"); // Singleton View/ViewModel which registers route via Routing.RegisterRoute with routeName = "Signup"
			
		return builder.Build();
	}
}

In addition to registering the Views and ViewModels in MAUI IoC container, the extension methods also uses generic type constraints for ViewModels to ensure they implement INotifyPropertyChanged.

This can be helpful in tightening the inner loop by failing builds when a developer adds a new Page and ViewModel but forgets to inherit from ObservableObject or another class implementing INotifyPropertyChanged, use the [INotifyPropertyChanged] source generator attribute, or implement INotifyPropertyChanged directly.

[rjygraham]

Question for @brminnick @VladislavAntonyuk, are your 👍indicative that this discussion has received maintainer approval and ready to move feature proposal via converting this to an issue?

[bijington]

We need to vote as a team to get things approved and we usually do this during our community standup on the first Thursday every month. I can make a note to bring it up at the next one.

[TheCodeTraveler]

Yup! @rjygraham Go ahead and open a New Feature Proposal for this.

And, as Shaun mentioned, once you've opened the Proposal, we'll vote on it in an upcoming Standup. If the majority of the maintainers approve the API Design, you can then move forward with implementing it, adding Unit Tests and writing the docs!

Here's some of my thoughts that you're welcome to incorporate into the Proposal:

• Naming
  • Should we use MVVM terminology instead of Page?
    • E.g. AddSingletonViewWithViewModel
    • I personally don't hate AddSingletonPage, but adding View and ViewModel to the API better indicates that it's a View + View Model and meant for MVVM
  • Maybe we add Shell into the naming for routing, e.g. AddSingletonPageWithShellRoute
    • As far as I know, Routing is exclusively for Shell
• Constraints
  • How do we constrain TPage?
    • Maybe where TPage : Microsoft.Maui.Controls.Page?
      • This would cover ContentPage and TemplatedPage
    • Maybe where TPage : Microsoft.Maui.Controls.View?
      • This would allow for greater flexibility to allow for smaller MVVM submodules
      • For example, we use MVVM for Popups in the sample app
        • The View is inheriting from Popup
        • It has its own ViewModel/BindingContext, CsharpBindingPopupViewModel, which is separate from the ContentPage's ViewModel/BindingContext
  • How do we constrain ViewModel?
    • Maybe where TViewModel : INotifyPropertyChanged?

[bijington]

Would it be odd to have separate View and Page specific methods?

Another item I wasn't entirely sure on was the fact that some of these methods are heavy on MVVM, we aren't explicitly an MVVM package so does it fit? I still think so and we state that it's there to use if you want to.

Do we also need to have Scoped registration methods as well as Singleton and Transient?

[rjygraham]

@brminnick re: naming, I'm onboard with being more verbose and descriptive than not. I believe INotifyPropertyChanged is likely the best constraint for ViewModels but I'm on the fence re: constraining TPage by Microsoft.Maui.Controls.Page or Microsoft.Maui.Controls.View

I think we should consider having separate methods for Views and Pages as suggested by @bijington.

@bijington, I agree re: these methods being very MVVMish and potentially a better fit for CommunityToolkit.Mvvm; however since the Views are constrained to Microsoft.Maui.Controls.Page and/or Microsoft.Maui.Controls.View and the Shell Routing is all MAUI specific, I believe this is the only viable home.

Finally, for the sake of completeness we could consider adding Scoped methods; however, I can't think of an instance where that would be applicable. I suppose potentially popups? I've usually only ever wanted a view/viewmodel to be a singleton or created fresh every visit.

I'll work on getting this turned into a New Feature Proposal tomorrow. Appreciate the feedback and great dialog so far!

[CliffAgius]

Closed as per the Community Stand-up discussion here: https://youtu.be/N9wMcBP4jtg?t=2889