Using Blazor server components without ending whitespace in wrapping container places the last component first

[Gebov]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

I am using a standard razor pages application and using Blazor Server rendering to it. There are lots of articles on how to do this. This is just one.

If you render the same component (or different ones in the same wrapping container) without leaving a new line before the closing wrapping tag at the end like so:

<div>
@(await Html.RenderComponentAsync<TestComponent>(RenderMode.Server, new { Title = "Test 1" }))
@(await Html.RenderComponentAsync<TestComponent>(RenderMode.Server, new { Title = "Test 2" }))
@(await Html.RenderComponentAsync<TestComponent>(RenderMode.Server, new { Title = "Test 3" }))</div>

It will render the components in a different order - placing the last one (Test 3) first:

Expected Behavior

I would expect the components to be rendered as they are placed in the code like so:

Steps To Reproduce

I am using a starter template for a razor pages app and just added my custom blazor component to it. All there is to do is to run the app, it would automatically open the Index page.

The changes are in the Index.cshml file.
WebApplication1.zip

Exceptions (if any)

No response

.NET Version

6.0

Anything else?

A workaround would be to add a new line before the closing wrapping tag.

<div>
@(await Html.RenderComponentAsync<TestComponent>(RenderMode.Server, new { Title = "Test 1" }))
@(await Html.RenderComponentAsync<TestComponent>(RenderMode.Server, new { Title = "Test 2" }))
@(await Html.RenderComponentAsync<TestComponent>(RenderMode.Server, new { Title = "Test 3" }))
</div>

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

Thanks for contacting us.

We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.