Using the same @key value on two different elements fails in a strange way (attributes disappear)

[gdar91]

Update from @SteveSandersonMS: After discussion below, the original usage pattern was not supported, but the way it fails is strange and unexpected. Ideally we'd make this fail in a more understandable way.

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Whenever I use the @key attribute on a plain HTML element, it messes up its attribute values. It happens, when you have elements with the same keys in different conditional branches.
This is a simple example, based on the famous Counter component in the blazer template. I've modified it to display odd and even numbers in different colors and apply CSS transitions between them. So I want the rendering engine to preserve the element between redraws for CSS transitions to work.

<p role="status">
    Current count:
    @if (currentCount % 2 == 0)
    {
        <span @key='"count"' class="count even">@currentCount</span>
    }
    else
    {
        <span @key='"count"' class="count odd">@currentCount</span>
    }
</p>

Counter.razor.css

.count {
    transition: color ease 1s;
}

.count.even {
    color: royalblue;
}

.count.odd {
    color: orange;
}

Knowing the purpose of the @key attribute, I thought this code would work, but it doesn't. When I click the increment button, the odd cases work well, but the even cases, render the span without any attributes.

Expected Behavior

No response

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

7.0.103

Anything else?

No response

[SteveSandersonMS]

I'm afraid the way you're using @key will not preserve the element when count changes. In fact the exact opposite - by changing the key, you're guaranteeing the element must not be preserved.

If you want to preserve the element, use something like:

<p role="status">
    @{ var cssClass = currentCount % 2 == 0 ? "even" : "odd"; }
    Current count:
    <span class="count @cssClass">@currentCount</span>
</p>

[SteveSandersonMS]

Oh sorry my mistake - the way you're using @key doesn't change when currentCount changes, so I see why you thought it would preserve the element.

However, elements are only preservable if they are the same element in your source code (and the framework knows this based on the sequence numbers that the Razor compiler generates). It's not meaningful to use the same @key value on two different elements, as you have done in your sources. Otherwise we'd end up in situations where people are trying to "preserve" an element while changing its tagname completely.

So in summary the alternative implementation I gave is still the recommended way to achieve this.

[gdar91]

Oh sorry my mistake - the way you're using @key doesn't change when currentCount changes, so I see why you thought it would preserve the element.

However, elements are only preservable if they are the same element in your source code (and the framework knows this based on the sequence numbers that the Razor compiler generates). It's not meaningful to use the same @key value on two different elements, as you have done in your sources. Otherwise we'd end up in situations where people are trying to "preserve" an element while changing its tagname completely.

So in summary the alternative implementation I gave is still the recommended way to achieve this.

But the actual behavior, which renders some cases without any attributes and other ones normal still doesn’t seem right. This is a very simple example I gave just to demonstrate the issue, and your suggestion is the way to go in this case, but some cases are more complex. For example, when the same element may come from different loops (a classic Before-Selected-After model of a selected list). I went with just wrapping the html elements inside components and it worked

[SteveSandersonMS]

But the actual behavior, which renders some cases without any attributes and other ones normal still doesn’t seem right.

You're right - we should make it fail in a more obvious and predictable way. I'll update the issue title to reflect that.