I like to return errors as text/plain and I have a global event handler for failed requests that throws up a dialog element. That takes care of most things.
Where appropriate, I use an extension that introduces hx-target-error and hx-swap-error, so I can put the message into an element. You can even use the CSS :empty selector to animate the error message as it appears and disappears.
Usually the default behavior, keeping the form as-is, is what you want, so users don’t lose their input and can just retry.
I had a site where the user can upload a file < 5MB. There may be a way to check this on the frontend, but for security reasons, it has to be checked on the backend too.
If it exceeds it, I returned 400. I had to add an event listener to check for the code (htmx:afterRequest) and show an alert(), but this gets difficult to manage if there's multiple requests to different endpoints on the page. Looking at it now, maybe I should have configured HTMX to swap for 4xx.
I have something similar on my website, and my solution was to make server driven modal/toast responses.
Allow the server to return a modal/toast in the response and, in your frontend, create a "global" listener that listens to `htmx:afterRequest` and check if the response contains a modal/toast. If it does, show the modal/toast. (or, if you want to keep it simple, show the content in an alert just like you already do)
This way you create a generic solution that you can also reuse for other endpoints too, instead of requiring to create a custom event listener on the client for each endpoint that may require special handling.
At the time I used headers to indicate if the body should be processed as a trigger, due to nginx header size limits and header compression limitations. Nowadays what I would do is serialize the toast/modal as a JSON inside the HTML response itself then, on `htmx:afterRequest`, parse any modals/toasts on the response and display them to the user.
> As it described on Clickhouse documentation, their API is designed to be READ ONLY on any operation for HTTP GET As described in the Clickhouse documentation, their API is designed to be READ ONLY on any operation for HTTP GET requests.
Please disclose AI use, or the name of your "writing agent" at least, so I can know to skip the article. So much "it's not X it's Y" in this post, I'm losing it.
> This isn’t whimsy; it’s how I remember who the work is actually for.
> These aren’t chatbots with personalities; they’re specialized configurations I invoke by name to focus my intent.
> That’s when I realized the naming wasn’t a quirk. It was a practice.
It is a quirk
> I’m not asking for a generic security scan. I’m saying that I need to look for what I missed.
You aren't asking for a generic security scan? It seems like you're asking for a generic security scan.
> I need to look for what I missed. I need to find the secret traveling farther than it should, the data leaking where it shouldn’t, the assumption I made that an attacker won’t make. I need to be paranoid on behalf of the users whose data and trust I’m protecting.
> The names aren’t just labels. They’re invocations. They shape my intent before the work even starts.
At least right now it's mostly in AI-related articles. Scroll any AI article and have a look at the number of topic headings as well as how many start with the word "The". I have my defenses up on any AI articles and can quickly avoid the are LLM-output with aesthetic clues. An upfront disclosure would of course be better.
Unfortunately other topics are still catching me off guard, like the article about complex numbers posted today which I managed to get through a third of before realizing all the grating bits I was reading were because it was from an LLM.
reply