Suggestion: Enable Navigation Service to cope with wrapped Viewmodels

[ghost]

I have a project where I'm using awrapper around my ViewModels. This is currently not supported by the NavigationService.

I suggest adding an override to the code extracting the DataContext.

More specifically. These three NavigationServices methods break when the ViewModel is wrapped:

• NavigateToAsync
• NavigateFromAsync
• NavigatingFromAsync … i.e. “page.DataContext as INavigable” returns null.

To enable a work-around, add this function Navigation Services:

protected virtual INavigable ExtractNavigable(Page page) { return page.DataContext as INavigable; }

And replace the three instances of page.DataContext as INavigable with ExtractNavigable(page).

With those few changes it will be possible to extend the NavigationService like this:

`public class NavigationServiceEx : NavigationService, INavigationService { public NavigationServiceEx(Frame frame) : base(frame) { }

    protected override INavigable ExtractNavigable(Page page)
    {
        return ForView.Unwrap<dynamic>(page.DataContext) as INavigable;
    }
}

` ... and

`public class BootStrapperEx : BootStrapper { public override async Task OnStartAsync(StartKind startKind, IActivatedEventArgs args) { await Task.CompletedTask; }

    protected override INavigationService CreateNavigationService(Frame frame)
    {
        return new Services.NavigationService.NavigationServiceEx(frame);
    }
} `

[JerryNixon]

Yikes, that's a complicated addition. Your wrapper can't simply implement INav and pass along?

[ghost]

No, the challenge is that the wrapper is part of another Nuget. In my case it's Assisticant, which I really like working with. But I suspect that there are other scenarioes where ViewModel/DataContext is wrapped too for good (or bad) reasons.

Regarding complexity. I don't see it that way and all that is added to the NavigationService implementing is a method and the ability to override it. Why is that complex?

To clarify: The class NavigationServiceEx and BootStrapperEx are just for refrence and not part of the suggested change, but just an example of how to utilize the proposed "virtual INavigable ExtractNavigable" when and if needed. I've tested it and it works fine.

[artfuldev]

BindableBase kind of already provides what Assisticant does, to an extent, from the looks of the home page. However, may be it does much much more...

[1iveowl]

No, Assisticant goes beyond that of BindableBase and is much cleaner to my taste. In short Assiticant provides a more clean and stateless ViewModel: https://www.pluralsight.com/courses/clean-view-models-assisticant

[artfuldev]

That's why I added "However, may be it does much much more...", because I wasn't familiar with it. I based my comments with just what I saw on the home page. Thanks for the course link :+1:

[1iveowl]

Ok :-)

You're welcome. I can recommend the course and that particular way of working with ViewModels . Then of course everyone has their own taste ;-)

[1iveowl]

There is a proposed solution in PR #621 that adds the capability for unwrapping ViewModels by using the proposed ResolveForPage(Page page, NavigationService navigationService).