Benefits of nested classes & forced Initialize() implementation?

[Eagle3386]

Hi, there!

I started using BlazorState, but immediately wondered what's the reason behind nested classes & forced implementation of State<TState>.Initialize():

Nesting IAction-based classes within MyState class require Mediator.Send(new MyState.MyAction { … }) instead of Mediator.Send(new MyAction { … }) - what's the benefit of enforced nesting for consuming developers?

The docs of Initialize() state: Override this to Set the initial state - given that properties not only offer initialization by themselves, but even in multiple ways: what's the reason behind this decision?
Because this causes each State<TState>-derived class to contain 3 unused lines:

internal partial class MyState: State<MyState>
{
  public int Count { get; init; } = 5;

  public override void Initialize()
  {
  }
}

To me, it seems like most of the time, an IAction-derived class is pretty much like an EF POCO, i. e. it contains nothing but properties. So, may I ask what's the benefit for consuming developers?

[StevenTCramer]

Blazor state uses the nesting to determine the State the action acts on. The Clone Pipeline Behavior will automatically clone the state the action is nested in. And if something fails in the handler will reset that state.

This also makes it clear that an Action has a single Handler, which is also nested in the State (This gives it the ability to access private members) thus keeping everything nicely encapsulated.

BTW: Notifications on the other hand can have many handlers.

[Eagle3386]

Thanks for the explanations, helps quite a bit.

Though, stepping in via F12 (ReSharper or "plain" Visual Studio) always gives the state or action class, but getting to the handler is more complicated. The only workaround that comes to my mind would be putting all nested classes in 1 file - but that's against common coding practices as well due to being public.. 😕

Additionally, can you please answer the Initialize() question, too? Because that in particular bugs me, given C#'s awesome object initializer feature or even property assignments via constructor.

[StevenTCramer]

The code that uses it is here.

  public object GetState(Type aType)
  {
    using (Logger.BeginScope(nameof(GetState)))
    {
      string className = GetType().Name;
      string typeName = aType.FullName;

      if (!States.TryGetValue(typeName, out IState state))
      {
        Logger.LogDebug(EventIds.Store_CreateState, "Creating State of type: {typeName}", typeName);
        state = (IState)ServiceProvider.GetRequiredService(aType);
        state.Initialize();
        States.Add(typeName, state);
      }
      else
        Logger.LogDebug(EventIds.Store_GetState, "State of type ({typeName}) exists with Guid: {state_Guid}", typeName, state.Guid);
      return state;
    }
  }

If you don't want to use Initialize and do everything in the constructor that will be fine. As you see Initialize is called after the object is Gotten from the ServiceProvider.

[Eagle3386]

Yes, but that still forces implementation like public override void Initialize() { } instead of being purely optional.
Additionally, it has no async counterpart that returns Task, too.