I think the check should be located closer to the "swap" logic to avoid relying on the DOM state of an element. Instead, we should try to rely on an item state from the @for perspective (i.e. whether it was moved/swapped).

@AndrewKushnir I would like to better understand the reasoning here. What repeater is doing, in this specific situation, is attaching views to the DOM - either new ones or previously detached while running the algorithm. In this sense we could have logic that always says "attach to the DOM". But I don't think that exact operation (ex. swap / move) should matter here as those are just higher level operations that are building on the detach + attach pair of primitive operations.

I'm all for fixing it in the "right place", just not sure what should be the logic on the repeater side to determine the hydration state. Let's chat!

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}