RenderFragments re-rendering and state

[Postlagerkarte]

I am having a question about render fragments.

My setup looks like this:

I created a component called Zone.razor which contains this code:

@code {

    protected override void OnInitialized()
    {
        ZoneService.Register(ChildContent);
    }

    [Parameter]
    public RenderFragment ChildContent { get; set; }
}

I created another component called Output.razor which renders the fragments:

@foreach(var frag in ZoneService.GetFrags())
{
    <div>
        @frag
    </div>
}

The ZoneSerive.cs is just keeping a List with the RenderFragments.

My index.razor looks like this

<Zone>
    <Counter></Counter >
</Zone>

<Zone>
    <Counter></Counter >
</Zone>
<Output></Output>

The <output> component renders the desired output , two counter components, and the components are working fine.

However, If a StateHasChanged event triggers re-rendering the state of the counter components are lost.

Is this supposed to happen?

Can you advise how to keep the state upon re-rendering?

[mkArtakMSFT]

Thank you for filing this issue. In order for us to investigate this issue, please provide a minimalistic repro project (ideally a GitHub repo) that illustrates the problem.

[Postlagerkarte]

@mkArtakMSFT : Thank you for taking the time to investigate.

Here is the github repo: https://github.com/Postlagerkarte/renderfragment

[Andrzej-W]

Probably you have to use @key
https://docs.microsoft.com/en-us/aspnet/core/blazor/components?view=aspnetcore-3.0#use-key-to-control-the-preservation-of-elements-and-components
You can also look here: #11908

[Postlagerkarte]

Thank you @Andrzej-W - I already played around with the key attribute before filling the issue but now I tried again and got it to work,

I was confused because if you render like this there is no way to set the key attribute in the foreach loop:

@foreach(var frag in ZoneService.GetFrags())
{
        @frag
}

Wrapping it in an extra div and it works:

@foreach(var frag in ZoneService.GetFrags())
{
    <div @key="frag">
        @frag
    </div>
}

@mkArtakMSFT : I assume that there is no way to improve the rendering internally so that there is no need to use key attribute in the first place?

[Postlagerkarte]

@Andrzej-W @mkArtakMSFT

Unfortunately adding a key only keeps the state of the renderfragment if the fragments stays within one output zone.

I updated the git hub repository (https://github.com/Postlagerkarte/renderfragment) to show the problem.

The fragments are still losing their state - even though the key property is assigned.

Basically the code looks like this now:

<Output ZoneId="1"></Output>
<Output ZoneId="2"></Output>

and the Output.razor:

@foreach(var frag in ZoneService.GetFrags(ZoneId))
{
    <div @key="frag">
        @frag
    </div>
}

[javiercn]

@Postlagerkarte Thanks for providing the repro.

The problem is that you are passing a RenderFragment to a component (Zone1,Zone2,N) and then passing that same through an alternative mechanism to the output component.

The problem is that RenderFragment is not a stateful UI piece of UI, but a function that represents the UI that needs to be rendered.

In your OutputComponent you are simply retrieving that function and re-running it, which re-creates the UI from scratch, hence loosing the previous state (as expected).

You can't reuse the same component instance in two separate places of the UI, the best alternative you have is to pass in the data from a model and keep the state out of the component.

Hope this helps.

[Postlagerkarte]

@javiercn : Thank you for taking the time to reply.

The context of my question is a drag and drop library I created in which a users can wrap anything in a draggable component and thus can drop it to an arbitrary dropzone.

This works like this:

<Dropzone>

        <Draggable>
            <Counter></Counter>
        </Draggable>

        <Draggable>
            <Counter></Counter>
        </Draggable>

</Dropzone>

For a single dropzone the components keep their state even when re-arranged and re-rendered. ( due to the use of the key attribute)

See here: https://blazordragdrop.azurewebsites.net/Components for a demo or here for the repo https://github.com/Postlagerkarte/blazor-dragdrop

I am pointing that out because you wrote :

"retrieving that function and re-running it, which re-creates the UI from scratch, hence loosing the previous state (as expected)."

However this is not the case in the above sample - the state is only lost when I add a second dropzone.

It seems the state is lost when a different parent component id is detected by the renderer and thus getcomponentstate can not find the state?

Would greatly appreactiate if you can elaborate a bit more on the situation and on any workaround because this problem basically renders my library unusable for stateful components.

Thank you!

[Postlagerkarte]

@javiercn : Sorry to post again, just want to clarify my above posting:

My main question is:

"RenderFragment is not a stateful UI piece of UI" - which implies you can't pass it around and expect the state to survive it.

But why does this work and keeps the state:

@foreach(var frag in ZoneService.GetFrags())
{
    <div @key="frag">
        @frag
    </div>
}

Where as this doesn't work and the state is lost:

@foreach(var frag in ZoneService.GetFrags(ZoneId))
{
    <div @key="frag">
        @frag
    </div>
}

[javiercn]

But why does this work and keeps the state:

Because keys don't expand multiple components. The Blazor diff algorithm diffs component tree's individually. In the first case, there is a component tree that looks something like

component="component"
element=div
key=1
{...}
element=div
key=2
{...}
element=div
key=3
{...}

While in the second case I understand each fragment is enclosed within a component
component="component"
element=div
key=1
{...}
component="component"
element=div
key=2
{...}
component="component"
element=div
key=3
{...}
component="component"
element=div
key=4
{...}

In the first case, the key can be used to detect the re-ordering and keep the internal components (preserving their state), and in the second case it can't.

This behavior is by design, and something fundamental to make rendering efficient, so you need to take it into account in the design of your component.

I believe your options are to either follow the pattern in option 1 or to pass in a model to the components that hey use to render.