-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make response code behavior configurable for the end user #199
Comments
Hi Paul, Reading the spec here: https://tools.ietf.org/html/rfc7231#section-6.3.5 And the dev page on the mozilla site: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/204 Our thinking was that this was used primarily for a PUT where the DOM content did not change. Given the spec I think this is a reasonable interpretation and default implementation. However, we should let you, the end user, modify that behavior if something else makes sense in your case. I have updated this issue's title to reflect that we should be allowing you to do this. In the meantime, can you modify a local version of htmx to behave how you would like? |
Thanks. I'm good for now... I'll either change my API response for DELETE or modify a local version of htmx. Other parts of RFC 7231 state that a DELETE should return 204 if there is no content, but I guess a case can be made that empty content is not the same as no content, and if I want to remove an element in the DOM that requires empty content, I should send empty content. I'll probably spend much more time worrying about this than I should. |
Well, it is an interesting question; as opposed to other well-established models, HTMX is exploring a new client/server interaction pattern. The challenge is that 204 No Content could be used for a number of things (state transition, sending out notifications, etc), not just DELETE. Hence we should have a way to declare what should be done. Perhaps the default behavior should depend upon the method? Do you mind explaining your use case in more detail? Is this a button on each row in a table, for example? In that case, clicking delete should probably result in removal of the row. |
Exactly that, but it could also be a button inside a div, where the div represents the the thing to be deleted. There are probably other configurations as well, but the main idea is there some visual representation of an item that can be deleted, an associated button to do the delete, and I will want to remove the item visually when the server responds with 200 or 204.
I'm just getting started with htmx, but I would have thought that the default behavior of htmx would be independent of both the method and the response code, if only because it would quickly get out of hand otherwise. That's why I was surprised that 204 didn't do anything. However, I'm just getting started and am not even aware of all the behavior and all the defaults, so my surprise is not necessarily a good indication of anything. From what I have seen, 204 and 304 are currently special cased. What about 412 from, say, a conditional delete? I do conditional deletes, so I will want different behavior than simply removing the element if the condition is not met. If the "response code behavior is configurable for the end user"- what is that going to mean? Would it include doing two different things for two different codes? For example for 200 I want to swap outerHTML on target A, while 412 would swap innerHTML on target B? But I'm getting way ahead of myself here.... |
I just stumbled over the same thing. In my case I was also intuitively returning a 204 after a DELETE. This interaction reflects the "X" button on a message that informs the user about an error that occurred and the user can dismiss that message. I'm going to return an empty result for now, but I was expecting "native HTTP" to work with a 204. |
@ctheune, as mentioned in #1130 (comment), the behavior of HTMX can be altered to allow content swapping for document.body.addEventListener('htmx:beforeSwap', function(event) {
if (event.detail.xhr.status === 204) {
// Swap content even when the response is empty.
event.detail.shouldSwap = true;
}
}); No need to change your API. :) |
I was surprised that with a 204 response and
hx-swap
set to "outerHTML" or something similar, htmx did not replace the content with nothing (i.e., no content). A little research (comment on Issue #138 with a reference to commit #d5f6ef2) shows that it was a design decision to ignore 204 responses. I could not find a larger or more detailed discussion about this.My API currently returns 204 No Content for deletes. I could change this to return 200 OK with zero content, but should I have to?
I was under the impression that a 204 is a very acceptable result for a delete, in fact a more acceptable result than 200 if there is never any expected content. Also it would seem that it is a very common pattern to replace content with nothing on the client (i.e., delete the content) when doing a delete on the server. It seems like I should not have to rewrite my API in this case.
What is the rationale for not processing a 204 response like a 200 response with no content? The programmer could always set
hx-swap
to "none" to achieve the current behavior I think.I'm sure I'm missing something.
The text was updated successfully, but these errors were encountered: