[MVUX] Naming -and namespace- of generated classe (a.k.a. proxies)

[dr1rrb]

Actual state

Let assume the sample:

namespace MyApp;

public record Countable(int Step, int Value); // The "Entity"

public record CounterModel // The "Model"
{
    public IState<Countable> Counter { get; }

    public ValueTask Increment()
        => Counter.UpdateAsync(c => c with { Value = c.Value + c.Step });
}

Currently we will generate:

namespace MyApp;

public class BindableCountable { /* ... */  }

public class BindableCounterModel { /* ... */ }

1. Root proxy

The class BindableCounterModel is generated in order to be used as the root data-context of a MVUX object model. Typically we expect it to be used as DataContext of the Page

This will re-expose all properties exposed by the CounterModel (methods being converted as ICommand).

Trigger

This generator triggers on CounterModel because:

1. It's name ends by "Model" (configurable)

2. Sub proxy

The class BindableCountable is generated by what we could name a "entiy generator". The purpose of this generator is to de-normalize properties the Countable to allow 2-way binding directly on each property (so for instance we can use a slider to set the Step: ```).

Classes generated by this generator are not expected to be used by end-users, they are instead expected to be referenced only by the code generated by the "root proxy" generator.

Trigger

This generator triggers on Countable because (and):

1. It's a record
2. It's being used in an IState property by a class that triggered the first generator.

The problems

Code gen

1. If a user want to name the Countable class "CountableModel", both "root" and "sub" proxies genertoir will trigger and will use the same filename / class name / namespace driving compilation to fail (cf. C# Markup + MVUX: More than one model named as <somethingModel> produces a source generator error. #2307 and [MVUX] Creating a State<XXXModel> break code gen if XXXModel is a record #2310)
2. As we generate code in application name-space, if a user have a class with a mathcing name, we might have conflict

Naming

We have confusion about what we call a "model". Currently it refers to both:

1. The "root" model written by the user, e.g. the CounterModel in our sample
2. The "sub" model, e.g. Countable in our sample.

In doc to avoid confusion we choose to name the second "entity" to avoid confusion.

Note: We kept the suffix "Model" for user-code in order to stay close to the "MVVM" pattern.

Proposal

Considering that

1. Naming convention still cause some confusion and keeping in mind "MVUX" name
2. As long as we are using application namespaces we risk a conflict

Current	Purpose	Current proxies NS	Proposal	Proposal proxies NS
Model	root-model / update the model	MyApp	Updater	MVUX.Updaters.MyApp
None / "Entity"	sub-model	MyApp	Model	MVUX.Models.MyApp

Also in order to reduce friction regarding custom namespace, the recommendation would be tu use inject in the updater a factory static method to create the ViewModel.

Example

Same example as above with new naming:

namespace MyApp;

public record Countable(int Step, int Value); // The "Model"

public record CountableUpdater
{
    public IState<Countable> Counter { get; }

    public ValueTask Increment()
        => Counter.UpdateAsync(c => c with { Value = c.Value + c.Step });
}

And generated proxies:

namespace MVUX.Updaters.MyApp
{
    public class CountableViewModel { /* ... */  } // root proxy
}
namespace MVUX.Models.MyApp
{
    public class CountableViewModel { /* ... */ } // sub proxy
}
namespace MyApp
{
    public partial CountableUpdater // extend the updater to ease view model discovery without needing to know the concrete VM type
    {
        public static MVUX.Updaters.MyApp.CountableViewModel CreateViewModel(/* ctor params */)
            => new MVUX.Updaters.MyApp.CountableViewModel(/* ctor params */);
    }
}

Unknown

1. Support of strong typing for C# markup?

[dr1rrb]

Suggestions from @francoistanguay

CounterModel
  IState<Counter> Counter
  IState<CountryModel> Country;

would become

CounterViewModel

CounterState?
CountryModelState?

[francoistanguay]

Idea is that MVUX source gen is responsible to generate a ViewModel from an immutable Model.

As for the IState classes, we'd generate a TState class that behaves today like a nested ViewModel.

The maine reason that we wouldnt name the generated class for IState as TViewModel is that the typical structure is to have a Model class containing an Entity like CounterModel countaining a Counter state. If both the State and CounterModel were both generated as CounterViewModel, it would clash on duplicate names.

[francoistanguay]

Also important to note that in C# Markup, the DataContext will be newed up with new CounterViewModel() instead of new BindableCounterModel() which aligns better with MVVM thinking.

And if you ever end up having to pass your sub stateto a builder extracted method, it would be something like: StackPanel Header(CounterState state) => new StackPanel().Children(new TextBlock().Text(() => state.Count));