Closed 314159265meow closed 1 year ago
Hello,
I can confirm the bug. I'm looking into it, thank you for letting me know. It does look like the link is as if it's going from another port (right or top/right)
Got it!
The issue is due to how Blazor detects changes inside a for loop.
Let's take the default node widget:
@foreach (var port in Node.Ports)
{
<PortRenderer Port="port" Class="default"></PortRenderer>
}
It happens that the deleted ports are:
Which leaves the Right port right? Yes! But because of the for loop & blazor, the Top port is still rendered instead.
To fix it, we simply need to use the @key
property:
@foreach (var port in Node.Ports)
{
<PortRenderer @key="port" Port="port" Class="default"></PortRenderer>
}
This also explains why it looks like in the demo that removing ports removes them anti clock wise. The thing is, it's random, so it shouldn't even look like that 😄
Thank you quick help, it did some very weird things for us, like rendering non attached links and eventually throw a JS exception ("getBoundingClientRect" of null).
The @key attribute fixes it perfectly.
Hi,
when you remove ports from a node, the other ports often get the wrong position and sometimes in our case have their
Initialized
property set to false. The results are not deterministic though, I think it a timing problem with the MutationObserver.You can test it in your demo. Browser: Chrome 104![Animation6_63](https://user-images.githubusercontent.com/13624874/184353672-7d4cadc8-54cc-4ad1-9def-3b10e0f6e4a6.gif)