This will be automatically applied when lambda expressions will be used too:

So I have to warn about when you using lambda instead of the method, because it will optimize when the expression are equals for example:

RegisterParameter(nameof(Spacing), () => Spacing, () => _increaseCounter++);
RegisterParameter(nameof(Max), () => Max, () =>  _increaseCounter++);

The increase counter will be called once, when someone might expect that the counter would increase twice, but it will be once.

But if you use bools like this

RegisterParameter(nameof(Spacing), () => Spacing, () => _childrenNeedUpdates = true);
RegisterParameter(nameof(Max), () => Max, () => _childrenNeedUpdates = true);

Then it should be fine, since you don't need to set the same boolean twice.
@henon you can add this warning to documentation if you want.

Codecov Report

Attention: Patch coverage is 96.22642% with 2 lines in your changes are missing coverage. Please review.

Project coverage is 88.95%. Comparing base (345ec7c) to head (1e3462e).

@@            Coverage Diff             @@
##              dev    #8384      +/-   ##
==========================================
+ Coverage   88.82%   88.95%   +0.13%     
==========================================
  Files         407      410       +3     
  Lines       12226    12264      +38     
  Branches     2441     2451      +10     
==========================================
+ Hits        10860    10910      +50     
+ Misses        834      826       -8     
+ Partials      532      528       -4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

at 4am got an enlightenment....
Instead of doing this:

var parameterChangeShouldFire = new HashSet<ParameterMetadata>(ParameterHandlerUniquenessComparer.Default);
var changedParams = _parameters.Where(parameter => parameter.HasHandler && parameter.HasParameterChanged(parameters)).ToList();

await baseSetParametersAsync(parameters);

foreach (var changedParam in changedParams)
{
	if (parameterChangeShouldFire.Add(changedParam.Metadata))
	{
		await changedParam.ParameterChangeHandleAsync();
	}
}

Which works great, but I can just do:

#if NET8_0_OR_GREATER
        var parametersHandlerShouldFire = _parameters
            .Where(parameter => parameter.HasHandler && parameter.HasParameterChanged(parameters))
            .ToFrozenSet(ParameterHandlerUniquenessComparer.Default);
#else
        var parametersHandlerShouldFire = _parameters
            .Where(parameter => parameter.HasHandler && parameter.HasParameterChanged(parameters))
            .ToHashSet(ParameterHandlerUniquenessComparer.Default);
#endif

        await baseSetParametersAsync(parameters);

        foreach (var parameterHandlerShouldFire in parametersHandlerShouldFire)
        {
            await parameterHandlerShouldFire.ParameterChangeHandleAsync();
        }

With extending the ParameterHandlerUniquenessComparer and allowing to compare the IParameterComponentLifeCycle too.
This way we have only one collection, and we can use the FrozenSet for .net8 which is 17% faster than the normal one because it's fixed size, an optimization never hurts especially in such important part.

So I have to warn about when you using lambda instead of the method, because it will optimize when the expression are equals for example:

Oh and if you will do

RegisterParameter(nameof(Spacing), () => Spacing, OnParameterChanged());
RegisterParameter(nameof(Max), () => Max, () => OnParameterChanged());

This will also be considered different, but I think it's all fine compromises considering that this string expressions are generated at compilation, we could just cover this with documentation. After all if we really need we could trim it down with regex in future,

Yes, passing an anonymous func calling the handler method ()=>OnParameterChanged() is useless complication anyway. Passing a method group OnParameterChanged is the best way to register a shared change handler and I'll document it that way.

So I have to warn about when you using lambda instead of the method, because it will optimize when the expression are equals for example:

RegisterParameter(nameof(Spacing), () => Spacing, () => _increaseCounter++);
RegisterParameter(nameof(Max), () => Max, () =>  _increaseCounter++);

The increase counter will be called once, when someone might expect that the counter would increase twice, but it will be once.

This would indeed be quite unexpected. Maybe we only optimize when a method group is passed? We can recognize anonymous functions because they contain =>.

This would indeed be quite unexpected. Maybe we only optimize when a method group is passed? We can recognize anonymous functions because they contain =>.

Yeah, we can add this to "exclusion rule" if you'd like

updated the code

It works. I never doubted that it would ;)

public partial class AbcXyzTestComp : MudComponentBase
{
    public AbcXyzTestComp() : base() {
        // abc shared handler group
        _a=RegisterParameter(nameof(A), ()=>A, OnAbcChanged);
        _b=RegisterParameter(nameof(B), ()=>B, OnAbcChanged);
        _c=RegisterParameter(nameof(C), ()=>C, OnAbcChanged);
        // xyz shared handler group
        _x=RegisterParameter(nameof(X), ()=>X, OnXyzChanged);
        _y=RegisterParameter(nameof(Y), ()=>Y, OnXyzChanged);
        _z=RegisterParameter(nameof(Z), ()=>Z, OnXyzChanged);
    }

    private ParameterState<int> _a;
    private ParameterState<int> _b;
    private ParameterState<int> _c;
    private ParameterState<int> _x;
    private ParameterState<int> _y;
    private ParameterState<int> _z;

    private void OnAbcChanged()
    {
        AbcHandlerCallCount++;
    }

    private void OnXyzChanged()
    {
        XyzHandlerCallCount++;
    }

    public int AbcHandlerCallCount { get; private set; }
    public int XyzHandlerCallCount { get; private set; }
    
    [Parameter]
    public int A { get; set; }

    [Parameter]
    public int B { get; set; }

    [Parameter]
    public int C { get; set; }
    
    [Parameter]
    public int X { get; set; }

    [Parameter]
    public int Y { get; set; }

    [Parameter]
    public int Z { get; set; }

}

I'll add a test for the lambda exception in the afternoon

Thanks for the bUnit tests, I was kind of lazy to do them 😭.

Wait you can use @bind-A="_a"

[Parameter]
public EventCallback<int> AChanged { get; set; }

?
I always though it was necessary for two way binding? And it's the examples I always saw.
I learned something new today.

Hmm, you are right, there is no need to use @bind- here, I'll remove it.

Thanks for the bUnit tests, I was kind of lazy to do them 😭.

No worries, I did promise to contribute the tests

Hmm, you are right, there is no need to use @bind- here, I'll remove it.

Oh don't worry, u can leave as it.
It was about that I'm surprised that the EventCallback is not necessary to use this syntax, I always thought the opposite.

Do we merge? I don't think I have anything to add.

I think it's ready to merge

at 4am got an enlightenment.... Instead of doing this:

var parameterChangeShouldFire = new HashSet<ParameterMetadata>(ParameterHandlerUniquenessComparer.Default);
var changedParams = _parameters.Where(parameter => parameter.HasHandler && parameter.HasParameterChanged(parameters)).ToList();

await baseSetParametersAsync(parameters);

foreach (var changedParam in changedParams)
{
	if (parameterChangeShouldFire.Add(changedParam.Metadata))
	{
		await changedParam.ParameterChangeHandleAsync();
	}
}

Which works great, but I can just do:

#if NET8_0_OR_GREATER
        var parametersHandlerShouldFire = _parameters
            .Where(parameter => parameter.HasHandler && parameter.HasParameterChanged(parameters))
            .ToFrozenSet(ParameterHandlerUniquenessComparer.Default);
#else
        var parametersHandlerShouldFire = _parameters
            .Where(parameter => parameter.HasHandler && parameter.HasParameterChanged(parameters))
            .ToHashSet(ParameterHandlerUniquenessComparer.Default);
#endif

        await baseSetParametersAsync(parameters);

        foreach (var parameterHandlerShouldFire in parametersHandlerShouldFire)
        {
            await parameterHandlerShouldFire.ParameterChangeHandleAsync();
        }

With extending the ParameterHandlerUniquenessComparer and allowing to compare the IParameterComponentLifeCycle too. This way we have only one collection, and we can use the FrozenSet for .net8 which is 17% faster than the normal one because it's fixed size, an optimization never hurts especially in such important part.

Unfortunately, using a Frozenset on .NET 8 on IOS (for a maui hybrid app), makes the application crash atm when using AOT in combination with the interpreter. Until this is fixed, I'd propose using the normal hashset for .NET 8 as well.

see:

CommunityToolkit/Maui#1752 (comment)

The workaround mentioned in this thread unfortunately makes the app crash completely.

Hi

Unfortunately, using a Frozenset on .NET 8 on IOS (for a maui hybrid app), makes the application crash atm when using AOT in combination with the interpreter. Until this is fixed, I'd propose using the normal hashset for .NET 8 as well.

see:

CommunityToolkit/Maui#1752 (comment)

The workaround mentioned in this thread unfortunately makes the app crash completely.

That's very unfortunate and big surprise that it's not working even with interpreter.
I will probably fix it in this #8416 PR as I'm about to merge it anyway.

Tho I have a question, have people tried only:

<PropertyGroup Condition="$(Configuration.Contains('Release')) And $(TargetFramework.Contains('ios'))">
	<MtouchInterpreter>-all,System.Collections.Immutable</MtouchInterpreter>
</PropertyGroup>

but not:

<MtouchLink>SdkOnly</MtouchLink>
<UseInterpreter>True</UseInterpreter>

?
upd: I left a comment - CommunityToolkit/Maui#1752 (comment)

<MtouchLink>SdkOnly</MtouchLink>
<UseInterpreter>True</UseInterpreter>

If people will report this is working for them, I will probably not change to normal HashSet, because this project properties are a must for iOS when using with MudBlazor for smooth experience anyway. We use some reflection, and without UseInterpreter it will not work, and this is documented in our repository.
If people say it's still crashing, then obviously this will be immediately changed.

<UseInterpreter> works but completely disables AOT compilation. That is quite the performance regression.

<MtouchInterpreter> leaves AOT enabled, but includes the interpreter for all stuff that cannot be AOT compiled.

However, I can now attest that it is the combination of UseInterpreter and that makes it fail. I did not have the conditions included. UseInterpreter is default in Debug builds, but not in Release builds.

So this statement works (both in debug and in release):

<PropertyGroup Condition="$(Configuration.Contains('Release')) And $(TargetFramework.Contains('ios'))">
	<MtouchInterpreter>-all,System.Collections.Immutable</MtouchInterpreter>
</PropertyGroup>

However this causes a crash:

<PropertyGroup>
	<MtouchInterpreter>-all,System.Collections.Immutable</MtouchInterpreter>
</PropertyGroup>

and this causes an exception (InvalidCastException)

<PropertyGroup>
	<MtouchInterpreter>-all</MtouchInterpreter>
</PropertyGroup>

UseInterpreter is default in Debug builds, but not in Release builds.

dotnet/maui#13019

That is quite the performance regression

What are the performance regression except the startup? I'm sorry, but I cannot imagine full AOT to be prod ready in MAUI for now, more drawbacks than benefits. Once you start to use reflection, expression etc you will need to use UseInterpreter (at least it was the case a year ago, hard to imagine that anything changed since then).

So this statement works (both in debug and in release):

<PropertyGroup Condition="$(Configuration.Contains('Release')) And $(TargetFramework.Contains('ios'))">
	<MtouchInterpreter>-all,System.Collections.Immutable</MtouchInterpreter>
</PropertyGroup>

Great, I think you should share it in the CommunityToolkit.

UseInterpreter is default in Debug builds, but not in Release builds.

dotnet/maui#13019

That is quite the performance regression

What are the performance regression except the startup? I'm sorry, but I cannot imagine full AOT to be prod ready in MAUI for now, more drawbacks than benefits. Once you start to use reflection, expression etc you will need to use UseInterpreter (at least it was the case a year ago, hard to imagine that anything changed since then).

UseInterpreter enables the interpreter and disables AOT compilation. Since iOS cannot JIT compile, this means that the entire application will be interpreted.

MtouchInterpreter will enable the interpreter for iOS only, and in addition will still allow AOT compilation. the -all indicates that all assemblies will be AOT compiled. System.Collection.Immutable will be interpreted (since it does not have the - in front of it.

<MtouchInterpreter>-all,System.Collections.Immutable</MtouchInterpreter>

see also:

https://learn.microsoft.com/en-us/dotnet/maui/macios/interpreter?view=net-maui-8.0