Skip to content
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

Open
PaulMansour opened this issue Sep 21, 2020 · 6 comments
Open

Make response code behavior configurable for the end user #199

PaulMansour opened this issue Sep 21, 2020 · 6 comments
Labels
enhancement New feature or request

Comments

@PaulMansour
Copy link

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.

@1cg 1cg changed the title 204 No Content Behavior Make response code behavior configurable for the end user Sep 21, 2020
@1cg
Copy link
Contributor

1cg commented Sep 21, 2020

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?

@PaulMansour
Copy link
Author

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.

@clarkevans
Copy link

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.

@PaulMansour
Copy link
Author

PaulMansour commented Sep 21, 2020

Do you mind explaining your use case in more detail? Is this a button on each row in a table, for example?

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.

Perhaps the default behavior should depend upon the method?

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....

@bencroker bencroker added the enhancement New feature or request label Sep 24, 2020
@ctheune
Copy link

ctheune commented Aug 3, 2023

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.

@asbjornu
Copy link

asbjornu commented Aug 27, 2023

@ctheune, as mentioned in #1130 (comment), the behavior of HTMX can be altered to allow content swapping for 204 No Content as well:

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. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

6 participants