MudSwitch on click interceptor? about mudblazor

[ScarletKuro]

Also I think a lot of components work this way currently:

Yeah, almost all input components are broken right now and doing fundamentally wrong things like updating the Value parameter and the ValueChanged parameter. They should use ParameterState and call the FieldChanged method from the state change handler, which already handles the change logic. However, modifying input components is difficult because they are tightly coupled.

[ScarletKuro]

This does not currently seem possible.

Hi,
Why does it seem not possible if MudSwitch supports two-way binding, which means you can intercept the state?
https://try.mudblazor.com/snippet/wEQokAvYgcmyfVZx

[KieranIrelandPD]

https://try.mudblazor.com/snippet/QOwSYqlbmDVZThXv

When using a MudForm and tracking FieldChanged, it does not honor the cancel.

[ScarletKuro]

Yeah, in v6 the FieldChanged event is not consistent. It might fire when the field has not changed and might not fire when it has.

In v7, it's at least consistent after this change: #8693. It fires in both scenarios—whether changed or not—but the formFieldChangedEventArgs.NewValue contains the correct value, and you can use this workaround:

<MudSwitch @ref="_mudSwitch" T="bool" Value="@Switch" ValueChanged="@OpenDialogAsync" />
private MudSwitch<bool> _mudSwitch = null!;
private async Task OnFormFieldChanged(FormFieldChangedEventArgs formFieldChangedEventArgs)
{
    if (formFieldChangedEventArgs.Field is MudSwitch<bool> mudSwitch)
    {
        if (mudSwitch == _mudSwitch)
        {
            if (!EqualityComparer<bool>.Default.Equals((bool)formFieldChangedEventArgs.NewValue, Switch))
            {
                HasChanges = true;
            }
        }
    }
    await InvokeAsync(StateHasChanged);
}

I don't think there will be any fix for v6 unless you want to make a hotfix PR.

@igotinfected, do you know if it's still a bug in v7 that for the switch, the FieldChanged event fires regardless of whether it was changed or not, or is this intended? I'm not much of a MudForm user.

[igotinfected]

Don't think it's necessary to trigger the FieldChanged event if the user decides to revert a value change. Currently we just don't handle that case. The change was already applied in the component, so form validation is called. In the meantime the user changes the value again (with the dialog in this case) but that is considered to be an extra change.

To handle this case we would have to not touch the Value of a component if a ValueChanged is provided and only do form validation after the component parameters are updated (with the parameter state framework for example). I tried messing around with the MudBooleanInput implementation to see if I could get this to work, I got it working halfway but always end up with an infinite update loop :/ Need to try again with a fresh mind 🤪

Also I think a lot of components work this way currently:

[ScarletKuro]

@henon @igotinfected Also, what I noticed while doing this workaround #9158 (comment) is that the FieldId is always different for the same instance whenever you access it.

It's because of this code:

MudBlazor/src/MudBlazor/Base/MudComponentBase.cs

Lines 79 to 81 in c15ea62

	public string FieldId => UserAttributes.TryGetValue("id", out var id) && id != null
	? id.ToString() ?? $"mudinput-{Guid.NewGuid()}"
	: $"mudinput-{Guid.NewGuid()}";

If the "id" attribute is not found, it will assign a random GUID, but this GUID will always be different because the property with => will be reevaluated.

Is this intended, or is it actually a bug and it should be something like this?

private readonly string _fieldId = Guid.NewGuid().ToString();
public string FieldId => UserAttributes.TryGetValue("id", out var id) && id != null 
             ? id.ToString() ?? $"mudinput-{_fieldId}" 
             : $"mudinput-{_fieldId}"; 

[igotinfected]

If the "id" attribute is not found, it will assign a random GUID, but this GUID will always be different because the property with => will be reevaluated.

Yeah looks like a bug, I think I did more or less the same logic for one of the input classes MudInput or MudBaseInput using the parameter state framework. That FieldId is only used in two places too, I remember wanting to get rid of it eventually

[henon]

yes it is a bug. the id should be cached

[igotinfected]

FYI working on a fix for MudBooleanInput, got it working for MudSwitch, just adding tests and checking for regressions, targetting v7+ though.

[igotinfected]

The MudCheckBox component is causing me trouble in conjunction with the parameter state, will most likely request some help / thoughts on that in the next few days :p

[ScarletKuro]

The MudCheckBox component is causing me trouble in conjunction with the parameter state, will most likely request some help / thoughts on that in the next few days :p

Your struggles also could be related to missing this: #9225 as it breaks ParameterState, or maybe something else. You can always ask me.