Document that SortableItemTemplate roots need a @key - #20
Conversation
|
Warning Review limit reached
Next review available in: 51 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull request overview
Updates the project documentation to explain why SortableItemTemplate consumers should apply a stable @key on the template root to avoid Blazor diffing mismatches after DOM mutations performed by the JS interop layer.
Changes:
- Adds a new README section describing the post-drag DOM restoration behavior and the resulting need for keyed rendering.
- Provides a concrete example showing where to place
@keyinSortableItemTemplate. - Explains why
SortableListcannot apply@keyinternally without changing consumer markup/CSS.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
|
||
| ### Put a `@key` on the root of your item template | ||
|
|
||
| After a drag, the JS interop layer moves the dragged node back to its original position so that the DOM matches the .NET model again, and the model change then triggers a normal Blazor re-render. That is a DOM mutation Blazor's renderer did not perform itself, so without a key its diff matches the reused elements up positionally and can associate the wrong element with the wrong item - typically showing up as stale text, a lost input value, or focus jumping to a neighbouring row. |
There was a problem hiding this comment.
Reworded to "pairs up the reused elements by position".
Problem
SortableListrenders its items with a plain unkeyed loop:The interop layer deliberately moves the dragged node back to its original DOM position before notifying .NET, so by the time the re-render runs Blazor is diffing against a tree it did not mutate itself. Without keys the diff matches reused elements positionally, which can associate the wrong element with the wrong item — stale text, a lost input value, or focus landing on a neighbouring row.
Implementation
This is a docs change rather than a code fix, because the library cannot key the items itself:
@keyis a directive attribute that must sit on an element or component frame, andSortableListonly invokes the template as an opaqueRenderFragment<T>. Adding a key internally would require wrapping every item in an extra element, changing the markup and CSS of every existing consumer.So the README now states the requirement explicitly, with an example and the reason it cannot be handled inside the component.
Happy to switch this to a keyed wrapper element behind an opt-in parameter instead if you would prefer a code-level fix.