It's harder to test initial navigation logic because of how everything is done in uno.extensions

[takla21]

On some app, we need to have conditional navigation depending on the application state. The fact that the initial navigation is done somewhere in uno.extensions, we have to workaround this so we somewhat control it afterwards.

// How we workaround it to control the initial navigation.

// Configured it so the root route of the app is ShellViewModel, so it should navigate there first
routes.Register(
    new RouteMap("", View: views.FindByViewModel<ShellViewModel>(), Nested: new RouteMap[] {
        new RouteMap("Login", View: views.FindByViewModel<LoginViewModel>()),
	new RouteMap("Main", View: views.FindByViewModel<MainViewModel>(), Nested: new RouteMap[] {
            [...]
        }
    });

// We have to put the logic in a async Task private method that has to be called in parallel in the ctor of the viewmodel
public ShellViewModel()
{
    _ = Start()
}

private async Task Start()
{
    if (isLoggedIn)
    {
        await _navigator.NavigateViewModelAsync<MainViewModel>(this);
    }
    else
    {
        await _navigator.NavigateViewModelAsync<LoginViewModel>(this);
    }
}

With that in mind, the fact that the startup logic is in parallel, it makes it impossible to test it, since we don't have a proper way to wait for it's conclusion properly. We were force to introduce hack, fortunately without add sleep.timer, so we could somehow isolate the startup logic

public ShellViewModel(bool shouldSkipStart = false) // Adding this flag that can be test to make sure the start method is not called twice.
{
    if (!shouldSkipStart)
        _ = Start();
}

// Expose this method publicly so it can be isolated when testing this part.
public async Task Start()
{
    if (isLoggedIn)
    {
        await _navigator.NavigateViewModelAsync<MainViewModel>(this);
    }
    else
    {
        await _navigator.NavigateViewModelAsync<LoginViewModel>(this);
    }
}

So we could do our testing like this

// Arrange
var vm = new ShellViewModel(shouldSkipStart: true)

// Act
await vm.Start()

// Assert
// Check if the right navigation has been done here depending on isLoggedIn

In summary, if we would have more control on initial navigation, it will make us understand more how it works while also being easier to test our custom initial navigation logic

[nickrandolph]

If we were to add an async Initialize method (eg InitializeAsync) that would be called during navigation immediately after constructor, would this make it easier for testing?

[takla21]

Yeah this would be a good start. Although the only question/concern I have with this solution, would it interfere with the shell navigation somehow if in the initializeAsync we would also need to navigate depending on business logic?