Hello! I'd like to propose a small but impactful change to the Sortable.js example in the documentation.
The Proposal
Change hx-trigger="end" to hx-trigger="update" in the sortable form example.
The Motivation
Current documentation suggests triggering the AJAX request on the end event. However, end is quite "noisy" because it fires every time a user releases an item, even if:
The user clicked an item without moving it.
The user dragged an item up or down but then moved it back to its original position.
In these cases, the order hasn't changed, but htmx still performs a POST request. This leads to redundant server-side processing and unnecessary database writes.
Benefits of update:
Efficiency: The update event fires only when the DOM order actually changes.
Better UX: It avoids "false positive" updates when the user cancels their action by returning the item to the same spot.
Production-Ready: This pattern more closely follows how developers should handle drag-and-drop persistence in real-world apps.
Note: I also considered the move event, but found it too verbose as it triggers continuously during the drag operation, making it unsuitable for htmx triggers.
https://github.com/bigskysoftware/htmx/blob/master/www/content/examples/sortable.md?plain=1#L40-L57
Hello! I'd like to propose a small but impactful change to the Sortable.js example in the documentation.
The Proposal
Change
hx-trigger="end"tohx-trigger="update"in the sortable form example.The Motivation
Current documentation suggests triggering the AJAX request on the end event. However, end is quite "noisy" because it fires every time a user releases an item, even if:
The user clicked an item without moving it.
The user dragged an item up or down but then moved it back to its original position.
In these cases, the order hasn't changed, but htmx still performs a POST request. This leads to redundant server-side processing and unnecessary database writes.
Benefits of update:
Efficiency: The update event fires only when the DOM order actually changes.
Better UX: It avoids "false positive" updates when the user cancels their action by returning the item to the same spot.
Production-Ready: This pattern more closely follows how developers should handle drag-and-drop persistence in real-world apps.
Note: I also considered the move event, but found it too verbose as it triggers continuously during the drag operation, making it unsuitable for htmx triggers.
https://github.com/bigskysoftware/htmx/blob/master/www/content/examples/sortable.md?plain=1#L40-L57