[traceroute66]

There's a lot to like about htmx, but one thing that does not sit well with me is its opinionated design decision that it will only render content if its sent with a 200 OK (tech TL;DR: shouldSwap defaults to false for non-200 response codes).

Most sane services will only return a 200 OK if, well, things went OK. Most sensibly designed services will return 400 range if an error has occurred that has been handled gracefully.

I am aware that you can kludge a hack in the form of a JS snippet to force htmx to render content on !=200, but it shouldn't be that way IMHO.

[sebazzz]

> Most sane services will only return a 200 OK if, well, things went OK. Most sensibly designed services will return 400 range if an error has occurred that has been handled gracefully.

Yes, but you are not designing your MVC controller as a REST service, and are not trying HTMX to your REST API directly. This makes sense if you think of it from this perspective, like the classic MVC view-rendering controller behind your HTMX page.

[loneboat]

Can you elaborate on this? I've seen HTMX and considered trying it out in some projects, but would like insight on how to best use it in a stack.

[recursivedoubts]

In htmx 2.0 we make response code handling a declarative situation:

https://v2-0v2-0.htmx.org/docs/#configuring-response-handlin...

A few people on the core team agree that htmx should always swap. It was perhaps a bad decision on my part, but it is fixable w/ a bit of config.

[thom]

This is all handled in an extension:

https://htmx.org/extensions/response-targets

I don’t know what kludge you’re referring to, it requires you to add basically two attributes to your HTML, it’s really no hardship at all.

[traceroute66]

> This is all handled in an extension

And why should I need to load an extension to handle a 400-series ? That's just nuts.

The kludge is loading the following JS snippet on your page:

   if(evt.detail.xhr.status >= 400 && evt.detail.xhr.status <= 499 ) {
      evt.detail.shouldSwap = true;
   }

[thom]

Every web framework has error handling features. These are HTMX’s. It’s two HTML attributes and you’re done, if you don’t want any of the additional functionality.

[danielvaughn]

I didn’t know that, that’s interesting. I’d expect 100-199 responses to be able to render a result as well, at the very least.

[andrewstuart2]

All response codes should really be able to contain content that doesn't look terrible. A 404 can be a nicely formatted "not found" page that's consistently styled and looks like the rest of the app, for example.

[traceroute66]

> I didn’t know that, that’s interesting.

Yeah, it caught me by surprise first time I used htmx. I spent forever trying to troubleshoot why it wouldn't render the error message, then I discovered it was the old "feature not a bug".