Backend error responses: Use 200 status code to allow easy swapping or not?

[sh-at-cs]

Background

By default, htmx doesn't perform swaps on error responses from the backend (i.e. status code 4xx or 5xx).

One could use the Response Targets extension and its hx-target-error attribute to facilitate this, but in vanilla htmx it doesn't seem to be the intended way to use htmx, requiring users to hack something together with error event handling, change the global error handling configuration etc.

In at least one issue discussion, there was a suggestion by an htmx collaborator to just return 200 responses from the backend for "anticipated" errors, with error messages included somewhere in the HTML to be swapped.

My questions

Are these responses with 200 status codes but error messages inside the returned HTML how htmx is "meant to" be used?

If so, how does that fit to its implicit mission (given some of the essays on the website) to be RESTful? Or is the way status codes are used in JSON-RPC-style "REST" another distortion of the original REST idea?

[Telroshan]

Hey, that's a very hot topic that I still hope to convince 1cg about, someday! 😎

See issue #1619 for more discussion on the matter

The responseHandling property was added to htmx 2.0 to tackle this error swapping topic, even though I personally think it's not enough (I use per-element error swapping logic so, a global config doesn't fit my needs), so to this day I still use my forked error swapping system embedded in htmx itself (see PR #1620 linked in the above issue)

For now, you'd likely want to use the response-targets extension anyway, as even if it's an extension, it is still a core one, so this is the "official" way to implement more advanced swapping strategies in your app as of today.

Also, note that there is an open issue in the extensions repo to add the ability to specify a different swap strategy per status code to response-targets, and not only a target, which once implemented should address most usecases.

As for my very personal opinion, I definitely think that returning 200 codes to render errors is not the way htmx should be used, HTTP status codes were invented for a reason, it'd be a shame not to use them!

Hope this helps!

[sh-at-cs]

Thanks for the thoughtful reply! 💐

Wanting to have different swap strategies instead of just targets is in fact one of the issues that keeps me from using the Response Targets extension (among some other issues for which I'll probably open another Discussions thread) - I didn't include it in the original question for fear of overloading it, as it is kind of a separate issue, but it's good to see that I'm not the only one struggling with this 🙂
I've upvoted the issues you linked & will keep monitoring them - we ended up introducing a custom attribute with similar functionality, so it's good to have something to put in TODO: Replace with [GitHub issue] once implemented comments that give some hope that all this custom stuff can one day be removed 😁