You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a Razor component contains a DynamicComponent and its type gets changed in a click event, other elements with @ref element references lose their ReferenceCaptureId and they get rendered as empty blazor:elementReference="" (not necessarily all other elements, sometimes just some of them).
When the exact same component is rendered in a full Blazor Server application, this does not happen, the id is rendered e.g. as _bl_75ef2312-3b13-4dfe-925b-b29a10026a50="" (with the Guid in the attribute name) and stays constant.
[Fact(DisplayName="Changing a DynamicComponent type should not null out the ReferenceCaptureId of other elements")]publicvoidTest001(){varcut=RenderComponent<DynamicContainer>();output.WriteLine($"Before changing DynamicComponent: {cut.Markup}");// All @ref elements have a blazor:elementReference GUIDGuid.Parse(GetRefRerenceCaptureId(cut.Markup,"h3"));Guid.Parse(GetRefRerenceCaptureId(cut.Markup,"button"));cut.Find("#button").Click();output.WriteLine($"After changing DynamicComponent: {cut.Markup}");// Issue: The @ref elements have an empty blazor:elementReference, thus this throws now:Guid.Parse(GetRefRerenceCaptureId(cut.Markup,"h3"));Guid.Parse(GetRefRerenceCaptureId(cut.Markup,"button"));}// Extract the blazor:elementReference Id string for a HTML elementprivatestringGetRefRerenceCaptureId(stringmarkup,stringelement){varre=newRegex($"<{element}.*blazor:elementReference=\"([^\"]+).*");varmatch=re.Match(markup);}
The TestContext.RenderComponent() should exhibit the same behavior as a Blazor Server application and leave the ReferenceCaptureId in place when a DynamicComponent gets rerendered due to a type change.
I remember looking at this previously a few years ago, and I think it is a limitation we cannot get around until we implement #48, which is something I want to attempt for v2.
The problem is that the Blazor renderer does not provide a value for @ref on re-renders when the element does not change, thus we cannot set the blazor:elementReference attribute again, and we currently do not have a way to keep track of that info ourselves from the previous render, since we recreate the DOM on each render.
Will have to take an second look and make sure my memory is correct.
Describe the bug
When a Razor component contains a
DynamicComponent
and its type gets changed in a click event, other elements with@ref
element references lose theirReferenceCaptureId
and they get rendered as emptyblazor:elementReference=""
(not necessarily all other elements, sometimes just some of them).When the exact same component is rendered in a full Blazor Server application, this does not happen, the id is rendered e.g. as
_bl_75ef2312-3b13-4dfe-925b-b29a10026a50=""
(with the Guid in the attribute name) and stays constant.Example:
Testing this component:
With this test:
Results in this output:
Expected behavior:
The
TestContext.RenderComponent()
should exhibit the same behavior as a Blazor Server application and leave theReferenceCaptureId
in place when aDynamicComponent
gets rerendered due to a type change.Version info:
Additional context:
The described problem was first encountered in the Blazor part of https://github.com/toniarnold/aspnettest in the
asptest.blazor.bunit
sample test of theasp.blazor
project with bUnit 1.8.15. There theId
is used toFind
an element, which works with Selenium in a Blazor Server application, but fails with bUnit: It seems that only the Id of a button below aDynamicComponent
gets nulled out. The other references in the test https://github.com/toniarnold/aspnettest/blob/master/src/asptest.blazor.bunit/CalculatorTest/CalculateTest.razor remain reachable in that case.I've submitted a pull request #748 which exposes the issue with above test case.
The text was updated successfully, but these errors were encountered: