Shell Routing through attributes on page (using source generators)

[jamesmontemagno]

Description

Today, we must register each page in the AppShell on startup such as:

    public AppShell()
    {
        InitializeComponent();

        Routing.RegisterRoute(nameof(DetailsPage), typeof(DetailsPage));
    }

However, it would be nicer to align with how ASP.NET Core routing works and make it an attribute on the page. Since this would require assembly scanning today, this should be implemented as source generators for optimal performance.

(Public) API Changes

[Route(nameof(DetailsPage))]
public partial class DetailsPage : ContentPage

{

}

This would generate code necessary to register the DetailsPage with the route of DetailsPage.

Usage Scenarios

See above :)

Backward Compatibility

Would be an added option and an upgrade from the existing mechanism.

Difficulty

Medium

[egvijayanand]

Would allow maintaining the page properties in one place and ASP.NET users would feel at home. Can be made as a core feature rather than addressing it via source generator.

[egvijayanand]

@jamesmontemagno Not only routing, Registering the Page and ViewModel into the DI container can also be included in the scope of this automation.

To make use of a Page in the Shell architecture, now both Page and ViewModel, if any, need to be registered in the DI container.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[egvijayanand]

Hi @jamesmontemagno @Redth,

Have created a prototype, using Attributes and Source Generator, to register Routes for Shell pages and register the Services on the .NET MAUI startup pipeline.

Will create a PR so that this can be reviewed and then integrated into the core product as this makes life much easier.

[egvijayanand]

Examples:

// Route address defaults to the value of that type using nameof construct
[Route]
public partial class HomePage : ContentPage
{
}

// Explicit route address, reference to a member of type is also supported
// Multiple routes, Changing the scope of registration, ViewModel association
// When ImplicitViewModel is set to true, SettingsPage will be translated to SettingsViewModel
// Support for specifying an explicit ViewModel type is also supported
[Route("settings", ImplicitViewModel = true)]
public partial class SettingsPage : ContentPage
{
}

// By default registered as Singleton
[Service]
public partial class HomeViewModel : BaseViewModel
{
}

// Registered as a Transient service
[Service(ServiceScope.Transient)]
public partial class OrderViewModel : BaseViewModel
{
}

// Registered as Scoped service using the TryAdd method construct
[Service(ServiceScope.Scoped, UseTryAdd = true)]
public partial class NavigationService
{
}

[egvijayanand]

@jamesmontemagno @Redth

Have raised a PR for this feature. Kindly review and let me know your feedback.

[egvijayanand]

Have renamed Service as MauiService as the former is already in use in the Android platform.

[PureWeen]

@egvijayanand @jamesmontemagno I created a discussion for this in the MCT

https://github.com/CommunityToolkit/Maui/discussions/1004

Curious if it makes sense to put something like this there? Then we can release and iterate on it faster?

I'd like to just start moving more add-on shell features into the MCT in general so we can release/iterate faster.