htmx
htmx copied to clipboard
bigskysoftware
hx-swap=delete: Bug or misleading documentation
The documentation on hx-swap for "delete" reads:
delete - Deletes the target element regardless of the response
I'm using this swap together with hx-delete with the server returning a 204 response. Contrary to what the documentation suggests the delete swap never happens with this response. When changing the response status to 200 or 201 the swap is handled correctly. There is no error suggesting that something has failed when using a 204 response status.
I'm not sure whether this is bug in the implementation of the delete swap or whether this is expected behavior and the documentation is misleading.
(Mock) Example:
<div hx-delete="/test" hx-swap="delete" hx-target="this" hx-trigger="click">Delete Me</div>
def test(request):
return HttpResponse(status=204)
When clicking the div the request is sent and a response is received by the client but the div remains. Changing to
def test(request):
return HttpResponse(status=200)
correctly deletes the div.
I think it falls under this:
Sometimes you might want to do nothing in the swap, but still perhaps trigger a client side event (see below). For this situation you can return a 204 - No Content response code, and htmx will ignore the content of the response.
So it makes sense, but also is misleading if you don't know the documentation upfront.
@pierscin Ah right, my mistake. I had not properly read that section. It would probably be good to include an "exceptions apply" notice to the hx-swap documentation.
Thank you👍
I had the same problem which I think others will have to, so docs should be changed, but I'm not sure the intricacies of which response does or does not trigger it else I would submit pull request. But something to the effect of "Deletes the target element if the response code is 200 or 201.."
This also confused me. It's not obvious that 204 will be handled differently. It's pretty standard to return a 204 after a successful delete operation.
Closing this to center the debate in #199 as it's older, and contains a workaround solution
