Shell Navigation with parameters in a type-safe contract

[TrueMoniker]

I am converting a simple app from Xamarin to Maui, and will be converting a large enterprise application in the future.
While I understand how to pass parameters, I feel the contract for the parameters is not type-safe. Whether using IQueryableAttribute or multiple use object-based navigation data, if I change one of the expected parameters and forget to update all the calls to that view, nothing throws an exception.

As a solution, I have created a class that a view model can inherit to provide a type-safe contract. In my own code, I've extended it to accept up to 3 parameters using polymorphism

/// <summary>
/// A view model with parameter. When opening this view model, you can call <code>{view model}.CreateParameters</code>, then navigate to the page, passing the parameters.
/// Can have 1 parameter. Can be extended to allow for more parameters
/// Inherits <see cref="ObservableObject"/> and implements <see cref="IQueryAttributable"/> 
/// </summary>
/// <typeparam name="TParam1">The parameter. Pay attention to the type</typeparam>
public abstract class ViewModel<TParam1> : ObservableObject, IQueryAttributable where TParam1 : notnull
{
    /// <summary>
    /// Create the parameters to pass when opening this view.
    /// </summary>
    /// <param name="param1">The parameter. Pay attention to the type</param>
    public static Dictionary<string, object> CreateParameters(TParam1 param1)
    {
        return new Dictionary<string, object>()
        {
            { nameof(TParam1), param1 },
        };
    }

    /// <summary>
    /// Part of <see cref="IQueryAttributable"/> . This is called when the navigation opens this view with parameters.
    /// </summary>
    public virtual void ApplyQueryAttributes(IDictionary<string, object> query)
    {
        var x = (TParam1)query[nameof(TParam1)];
        InitParameters(x);
    }

    /// <summary>
    /// Sets up the parameters
    /// </summary>
    /// <param name="param1">The parameter. Pay attention to the type</param>
    public abstract void InitParameters(TParam1 param1);
}

How it works:
-The view model that receives the parameter has a static method CreateParameters that can be called to generate the parameters in a dictionary, then the app navigation works as normal using the multiple use object-based navigation data

• The base class processes the parameters so the view model can use the variables in the InitParameters method.

Example:

// the page to open
var navigationParameter = MyViewModel.CreateParameters(new MyParameter());
await Shell.Current.GoToAsync("MyPageRoute", navigationParameter);

// view model that uses a parameter
public partial class MyViewModel : ViewModel<MyParameter>
{
    public MyViewModel()
    {
    }

    /// <inheritdoc/>
    public override void InitParameters(MyParameter myParameter)
    {
        //... use parameter...
    }
}

Pros:

• Parameters are type checked, so any changes will alert me with compiler errors if I forget to update the parameters
• The logic for creating the parameters is in the view model that receives the parameter, so any changes to the parameter contract occurs in the same class file.
• The processing for the parameters is standardized to reduce duplicated boiler-plate code.

Cons

• You create the parameters by referencing the view model's CreateParameter method, but then navigate to the view. This is starting to couple the two together, though not any more than the regular navigation with parameters does.
• The navigation has to reference the viewmodel of the view it is navigating to. Because of this, if your navigation occurs in one project referenced by another project that contains the viewmodel, you cannot call the navigation directly. Otherwise you create a circular reference. This is an unfortunate trade-off of type safety vs magic strings.
  • My preferred way around this is to create a helper to do the navigation, with the interface for the helper stored in a root project that both the viewmodel and parameter model can access. Then I rely on dependency injection to resolve the interface.