Inconsistent component initialization with Blazor SectionOutlet/SectionContent and CascadingValue

[matthetherington]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

With a in a layout:

MainLayout.razor:

@using Microsoft.AspNetCore.Components.Sections
@inherits LayoutComponentBase

@Body

<SectionOutlet SectionName="test" @rendermode="@RenderMode.InteractiveServer" />

and a simple page with a counter that has a variable inside a razor code block, along with a CascadingValue:

Home.razor:

@{
    var foo = "bar";
}

<CascadingValue Value="@(1)">
    <button @onclick="@(() => Task.CompletedTask)">Click</button>
    @foo
</CascadingValue>

<SectionContent SectionName="test">
    <TestComponent OnClick="@(() => Task.CompletedTask)" />
</SectionContent>

TestComponent.razor:

<h3>Hello World</h3>

The component underneath the<SectionContent> is re-initialized every time the counter button is clicked. If I put a breakpoint inside TestComponent.OnInitialized, it is hit every time the counter is incremented.

After changing:

var foo = "bar";

to

const string foo = "bar";

the breakpoint is no longer hit for each increment of the counter, and the same instance of TestComponent is kept around.

Similarly, removing the CascadingValue means the breakpoint is no longer hit:

@{
    var foo = "bar";
}

<button @onclick="@(() => Task.CompletedTask)">Click</button>
@foo

<SectionContent SectionName="test">
    <TestComponent OnClick="@(() => Task.CompletedTask)" />
</SectionContent>

The SectionContent itself is not disposed, just the component underneath it.

Also, if I move the SectionContent and it's ChildContent into a component of their own, initialization/disposal is only performed once. Like:

@page "/"

@{
    var foo = "bar";
}

<CascadingValue Value="@(1)">
    <button @onclick="@(HandleClick)">Click</button>
    @foo
</CascadingValue>

<SectionContentInComponent OnClick="HandleClick" />

@using Microsoft.AspNetCore.Components.Sections
<SectionContent SectionName="test">
    <TestComponent OnClick="@OnClick" />
</SectionContent>

@code {
    [Parameter] public EventCallback OnClick { get; set; }
}

Expected Behavior

TestComponent is not destroyed and recreated on each render.

Steps To Reproduce

https://github.com/matthetherington/BlazorSectionOutletIssueRepro

Exceptions (if any)

No response

.NET Version

8.0.303

Anything else?

.NET SDK:
 Version:           8.0.303
 Commit:            29ab8e3268
 Workload version:  8.0.300-manifests.b18aae85
 MSBuild version:   17.10.4+10fbfbf2e

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  15.0
 OS Platform: Darwin
 RID:         osx-arm64
 Base Path:   /usr/local/share/dotnet/sdk/8.0.303/

.NET workloads installed:
There are no installed workloads to display.

Host:
  Version:      9.0.0-rc.1.24431.7
  Architecture: arm64
  Commit:       static

.NET SDKs installed:
  6.0.401 [/usr/local/share/dotnet/sdk]
  7.0.404 [/usr/local/share/dotnet/sdk]
  8.0.300 [/usr/local/share/dotnet/sdk]
  8.0.303 [/usr/local/share/dotnet/sdk]
  9.0.100-rc.1.24452.12 [/usr/local/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 6.0.8 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.9 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.0 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.5 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.9 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.10 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.14 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.5 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.7 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.0-rc.1.24452.1 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.8 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.9 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.0 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.5 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.9 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.10 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.14 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.5 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.7 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.0-rc.1.24431.7 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
  x64   [/usr/local/share/dotnet/x64]

Environment variables:
  Not set

global.json file:
  /Users/matt/Code/BlazorSectionOutletIssueRepro/global.json

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

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

[javiercn]

Took a look at this and it is by design. Explanation follows

The key issue is RenderFragment identity and how Blazor's Razor compiler generates delegates.

The Root Cause: RenderFragment Caching Rules

When you have a local variable in a Razor code block:

@{
    var foo = "bar";  // Local variable in BuildRenderTree scope
}

<SectionContent SectionName="test">
    <TestComponent OnClick="@(() => Task.CompletedTask)" />
</SectionContent>

The Razor compiler generates a new RenderFragment delegate for the SectionContent's content on every render. This happens because:

1. The presence of var foo creates a local scope within BuildRenderTree
2. The Razor compiler doesn't cache RenderFragment delegates when there are local variables in scope
3. Each render creates a new delegate instance for the content

With const:

@{
    const string foo = "bar";  // Compile-time constant
}

The RenderFragment can be cached/reused because there's no variable state to capture.

Why SectionOutlet Recreates Components

Looking at the SectionOutlet source code:

builder.SetKey(fragment);  // Uses the RenderFragment as a key

SectionOutlet intentionally uses the RenderFragment instance as a key. When the key changes (different RenderFragment instance), Blazor's diffing algorithm:

1. Disposes the old SectionOutletContentRenderer
2. Creates a new one
3. Recreates all child components

This is Correct Behavior

This design is intentional and correct for several important reasons:

1. Correctness over optimization: It's always safe to recreate components when in doubt. The alternative (not recreating when needed) would be a bug that could cause stale state or incorrect behavior.

2. Predictable behavior: The framework treats RenderFragment identity changes as significant, ensuring that content from different sources isn't accidentally mixed.

Proving the RenderFragment Identity Theory

We can verify this is about RenderFragment identity by explicitly caching the delegate:

@code{
    private RenderFragment _cachedContent = null!;

    private void CachedContent(RenderTreeBuilder __builder)
    {
        <TestComponent OnClick="@(() => Task.CompletedTask)" />
    }

    protected override void OnInitialized()
    {
        _cachedContent = CachedContent;
    }
}

<SectionContent SectionId="Constants.SectionId" ChildContent="_cachedContent" />

With this approach, both var and const behave identically - the component isn't recreated because the RenderFragment identity remains stable.

[javiercn]

@guardrex could you add a note on the Section docs https://learn.microsoft.com/en-us/aspnet/core/blazor/components/sections?view=aspnetcore-9.0 to also cover this behavior?

When a SectionContent content changes (the RenderFragment is a different instance), Blazor will completely destroy and recreate the section instead of diffing the contents.

That is because unlike on normal rendering, content could come from two different components, and it doesn't make sense to diff content from two separate components and might lead to unexpected results.

[dotnet-policy-service]

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.