Using SupplyParameterFromQuery on arrays, Blazor Wasm triggers too many on OnParametersSet

[ggregg]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

With Blazor wasm template projet.

Set counter page like that :

@page "/counter"

<PageTitle>Counter</PageTitle>

<h1>Counter</h1>

<p role="status">Current count: @currentCount</p>

<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>


@code {

    [Parameter]
    public int currentCount { get; set; } = 0;


    // Comment this parameter to observe the difference in behavior
    [Parameter]
    [SupplyParameterFromQuery(Name = "ko-param")]
    public string[]? KoParam { get; set; }


    [Parameter]
    [SupplyParameterFromQuery(Name = "ok-param")]
    public string? OkParam { get; set; }

    private void IncrementCount() => currentCount++;

    protected override void OnParametersSet()
    {
        // Add breakpoint
        Console.WriteLine("OnParametersSet");
        base.OnParametersSet();
    }
}

And MainLayout like that :

@inherits LayoutComponentBase

<div class="page">
    <div class="sidebar">
        <NavMenu />
    </div>

    <main>
        <div class="top-row px-4">
            <button @onclick=OnClick>Test</button>
            <span class="mx-2">@DateTime.Now</span>
            <a href="https://docs.microsoft.com/aspnet/" target="_blank">About</a>
        </div>

        <article class="content px-4">
            @Body
        </article>
    </main>
</div>


@code {
    void OnClick() => StateHasChanged();
}

You need to click the test button with and without the string[] parameter.

• If the KoParam parameter is commented, OnParametersSet is not called when I click the Test button. This is what I consider the normal behavior.
• If the KoParam parameter is uncommented, OnParametersSet is called when I click the Test button. In my opinion, this is a malfunction.

Expected Behavior

The expected behavior is that when I use arrays in SupplyParameterFromQuery, the OnParametersSet event should not be called more than necessary

Steps To Reproduce

https://github.com/ggregg/blazor_SupplyParameterFromQuery_bug.git

Exceptions (if any)

No response

.NET Version

7.0.402

Anything else?

SDK .NET :
Version: 7.0.402
Commit: 791db8e2d8

Environnement d'exécution :
OS Name: Windows
OS Version: 10.0.22621
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\7.0.402\

Host:
Version: 7.0.12
Architecture: x64
Commit: 4a824ef37c

.NET SDKs installed:
2.2.207 [C:\Program Files\dotnet\sdk]
7.0.302 [C:\Program Files\dotnet\sdk]
7.0.402 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
Microsoft.AspNetCore.All 2.2.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.2.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.23 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.2.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.23 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 6.0.23 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 7.0.12 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
x86 [C:\Program Files (x86)\dotnet]
registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
Not set

global.json file:
Not found

Learn more:
https://aka.ms/dotnet/info

Download .NET:
https://aka.ms/dotnet/download

[MackinnonBuck]

Thanks for reaching out.

We think this is because Blazor is conservative when determining whether the set of parameters has changed. For array parameters, Blazor doesn't check each array element to determine whether the newly-supplied array parameter is different from the existing parameter's value. Therefore, even if the query does not change, Blazor invokes OnParametersSet again. This is different from the non-array string parameter, because Blazor does know how to compare string values for equality before invoking a new OnParametersSet call.

Could you please confirm whether the behavior you're observing is consistent with what I've described above? Thanks!

Hi @ggregg. We have added the "Needs: Author Feedback" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[ggregg]

Hi @MackinnonBuck. Yes, I confirm that this is indeed the observed behavior. However, instead of this somewhat complex behavior, wouldn't it be simpler to observe changes directly in the QueryString itself ?

[javiercn]

@ggregg it's not that simple.

Query string parameters get parsed and transformed into values, and from that point on, they are regular parameters.

We don't want to couple the diffing algorithm to the query string nor do we want to have a different behavior for query string parameters than for regular parameters.

Having an extra render is perfectly fine and should not constitute a problem.

[ggregg]

Yes, I understand @javiercn, things are not that simple. I am developing a management application that has many search forms. When the user initiates a search, I build a new QueryString containing the parameters and submit it using NavigationManager.NavigateTo(...). In the OnParametersSet, I recycle the page and send the API request... This approach allows me to manage navigation history easily and cleanly. Calling these APIs multiple times doesn't seem like an acceptable solution either. Therefore, I've decided to stop using SupplyParameterFromQuery when a page's QueryString can contain arrays.

This issue has been resolved and has not had any activity for 1 day. It will be closed for housekeeping purposes.

See our Issue Management Policies for more information.