x-sort and x-for out of sync #4192
Replies: 3 comments 7 replies
-
This is likely a bug caused by the effect scheduler trying to prevent infinite loops. |
Beta Was this translation helpful? Give feedback.
-
I did find the problem, and wrote up a solution that is nearly ready to PR. I did end up mostly just refactoring the entire x-for, so ensuring it satisfied all tests took a moment, but It should be much faster on top of making this work. |
Beta Was this translation helpful? Give feedback.
-
I'm looking into this too... They get out of sync because both sortable.js and alpine both attempt to modify the DOM and step on each other's toes, and there doesn't appear to disable sortable.js doing it's dom manipulation. Even if I try to fix them up, sometimes the components inside of the loop re-initialize and lose state, which is a no-go for me. I'm not sure why sortable.js was chosen for the sort plugin given this deficiency. It struck me as odd that the documentation had no examples with how to use it with |
Beta Was this translation helpful? Give feedback.
-
I've seen a couple references in other reports that the combination of x-sort and x-for are causing various forms of unexpected behavior. I'm running into what seems to be a pretty simple and clear case, so I wanted to explicitly document it and see if it's something I'm doing wrong or if this is currently a bug.
Codepen here: https://codepen.io/CraigAB/pen/WNWqyYd
When an item in the "Sortable" list is resorted, it immediately reverts to it's previous position, but it correctly maintains the new sort in the "Sorted" list. If the same item is sorted again into another position, it reverts to the last new position. It seems like everything is actually working behind the scenes, but the "Sortable" list UI is always one step behind the data.
Am I handling this incorrectly? Any current workaround?
Beta Was this translation helpful? Give feedback.
All reactions