Make follow up request to get HTML to swap in

[mfonda]

Hi all, new to htmx and trying to figure out the best way to accomplish the following:

• I have a page that displays a question and some answers, and I'd like to use htmx to manage the answers.
• I have POST endpoints to add or remove a answers. Responses do not include any HTML.
• I have a separate GET endpoint that returns the full HTML of the question, including all answers.

I'm trying to delete an answer then re-render the question.

If the POST endpoint returned the HTML, this would be easy to do:

<div id="question">
    ...
    <button hx-post="/delete-answer/123"
            hx-target="#question"
            hx-swap="outerHTML">Delete</button>
</div>

However, since the POST endpoint does not and I need to make a follow up GET request to get the HTML, I'm not sure of the best way to accomplish this.

What I'd like to be able to do is something like:

<div id="question">
    ...
    <button hx-post="/delete-answer/123"
            hx-get-after-post="/question/1" 
            hx-target="#question"
            hx-swap="outerHTML">Delete</button>
</div>

and it would swap in the HTML returned by GET /question/1 instead of /delete-answer/123.

What's the recommended way to implement something like this?

I've managed to get it working by following the idea in Solution 3 here: https://htmx.org/examples/update-other-content/#events, but I don't love this as it requires me modifying my endpoint to include the HX-Trigger header. I'd like to avoid having to modify the endpoint as it's used in other places. I feel like I'm missing an obvious solution here. Thanks!

[Telroshan]

since the POST endpoint does not and I need to make a follow up GET request to get the HTML

May I ask why? The benefit you get from modifying your backend endpoint is that you would solve the usecase in a single roundtrip to the server. The issue with the setup you're describing here, is that you'll have your client wait for the server answer to then fetch the updated question, wait again for the server answer before updating the UI, when the UI could be updated along the first response. As commonly, the longest delay is the roundtrip to the server, you'd be basically doubling the latency of your user action.

From what you're describing, it looks like you're not sending anything in the first response, it'd be a shame to not take advantage of it to return your updated HTML then! (Actually, even if you were, you could then rely on OOB swapping)

I'd like to avoid having to modify the endpoint as it's used in other places

I may be missing something there as well, but what's so wrong with having client-type specific code in the backend ? Several common headers allow you to make a backend endpoint that can serve different client formats (both in receiving and answering data), such as Accept, Content-Type and others.

Requests made by htmx will all have the HX-Request header set, you can use that in your backend endpoint to determine whether it's a htmx-context or not, and answer the correct format depending on that. Regarding htmx, it's a common usecase when it comes to redirections in a boosted context for example, where you want to use the HX-Redirect header for a htmx request but a standard HTTP redirection for a full page load.

If you really want to go with the double roundtrip approach though, HX-Trigger is indeed the way to go, which lets your endpoint's initial response trigger as many other requests as you want on the page, given there are listeners for the named event you defined.
And if you want a pure client-side option, then I guess you could achieve the idea you described above (hx-get-after-post) in an extension, or rely on htmx request cycle events to fire it. But as you probably guessed, I would strongly encourage the single roundtrip solutions instead!

Hope this helps

[mfonda]

Thanks for the advice. I initially wanted to avoid this as the endpoint is currently used in several different contexts, each of which requires different HTML to be returned. I felt it kept the code cleaner to have an endpoints doing one specific (e.g. delete, update, return HTML, etc) rather than having them do multiple things.

Performance wise, htmx is already an improvement over the existing approach, so I felt keeping the code simpler in exchange for having to make two requests was on okay tradeoff.

It shouldn't be too hard to restructure things to return the HTML though and still keep things nicely separated. I'll give this a go, thanks.