[Spec, WiP] Provide better hooks for shell so users can better tune services and service scopes

[PureWeen]

Description

• When a user is using Flyout navigation we should requery the service provider with each navigation. If the service is transient, it will recreate the page. If the user is using bottom tabs vs FlyoutPage then don't requery. This might become somewhat of a rabbit hole trying to guess what cases make sense to requery vs not.
• Roll back this pr https://github.com/dotnet/maui/pull/4281 so users don't have to register every page.
• Provide a better service hook when any page part is created so users can more easily tap into the service used to generate the page.
• Provide a better hook for creating a new MauiContext (service scope) for different parts of shell. This will give us the ability to "dispose" of service scopes which will enable users to trigger "IDisposable" paths.

[brunck]

Would rolling back the PR listed above still allow people to inject their viewmodels into the page constructors?

Assuming yes, another thing to consider is that people don’t always want to inject viewmodels, so it’s best to allow a parameterless constructor approach as well, if that still aligns with the goals here.

[PureWeen]

@brunck I don't totally follow your questions

You can already inject viewmodels into the page ctors on shell if everything is registered You can also already have parameterless contructors

[ederbond]

Any news of when we can expect this spec to materialize into a real production ready implementation? .NET 9, 10, 11? I've been asking for this since early previews of .NET 6 and nothing until now.

[albyrock87]

Regarding

Provide a better hook for creating a new MauiContext (service scope) for different parts of shell. This will give us the ability to "dispose" of service scopes which will enable users to trigger "IDisposable" paths.

I think the current API already provides RouteFactory and TypeRouteFactory classes which could be subclassed by ScopedRouteFactory:

class ScopedTypeRouteFactory : TypeRouteFactory
{
    public ScopedTypeRouteFactory(Type type) : base(type) { }

    public override Element GetOrCreate(IServiceProvider services)
    {
        var scope = services.CreateScope();
        var scopedServices = scope.ServiceProvider;
        var page = (Page)base.GetOrCreate(scopedServices);

        // Attach to some event which is triggered only when the page is removed the navigation stack
        page.RemovedFromNavigation += (s, e) =>
        {
            scope.Dispose();
        };

        return page;
    }
}

and then we can offer:

public static void RegisterScopedRoute(string route, Type type)
{
    RegisterRoute(route, new ScopedTypeRouteFactory(type));
}

It would be great to have an event at Page level which is triggered only when page is removed from navigation task. This would solve a lot of problems.

[ederbond]

Any news around this?

[ederbond]

It would be great to have an event at Page level which is triggered only when page is removed from navigation task. This would solve a lot of problems.

That would be amazing @albyrock87

[ederbond]

It has been +2 years since I've reported this bug for MSFT and they didn't come up with a proper solution, so to save your precious time consider completely ditching MAUI AppShell for now, and use the following library to workaround this issue: https://github.com/naveasy/Naveasy

[albyrock87]

@ederbond I've seen a few PRs improving the current Shell API coming in .NET9, but I don't have a complete overview at the moment.

Regarding Shell, I don't think it's necessary "bad": it covers a lot of uses cases.

I've created a library on top of it, you may take a look here: https://github.com/nalu-development/nalu

Cheers

[ederbond]

Hi @albyrock87 I've seen your library like a month ago, it's cool. I'm just not a big fan of being forced to do unnecessary inheritance on my Views/ViewModels so as a former contributor of the Prism library I've decided to create my own library to workaround it. At the current state, I see MAUI Shell as a very bad implementation, it's not acceptable to rely on something that doesn't allow you dispose your objects in a simple out-of-the-box way. This is a showstopper for me.

[Lucasian20]

@PureWeen Any update on this?