Unless you only consider the happiest path, as in "I develop on localhost with zero latency, 100% uptime, and my backend validation logic perfectly matches my frontend policies" (and probably a lot more other "if"s and "only"s).
If the HTTP request that htmx has made returns a status code >= 400 or times out then the response will not be swapped into the body.
There are several events that htmx fires, once of which can catch `responseError` [1] and you can write some Javascript to handle it according to your requirements (throw a toast, swap anyway by setting `evt.detail.shouldSwap = true`.
In a project I'm working on we use htmx to load the content for modals, so we have small handlers on htmx events to display the modal whilst the request is being made, put a spinner indicator in the modal body to show the user something is happening and then swap the body in once the request has completed.
We've also used `HX-Trigger` response header [2] which htmx helpfully catches and allows us to easily hook onto, we've got ones to display a toast notification, hide open modals, refresh content divs, untick bulk action checkboxes, etc.
All in, our project probably has around 200 lines of Javascript for the different event handlers we do, so it doesn't eliminate the need to write any JS, but it's significantly reduced and is pretty much all event handlers.
so would you say that one of the first things a htmx based project should do is handle all the error conditions ? like all the 40x and 50x ? and stuff like your modal thinggy ?
how do you develop the js here ? do you setup a different nodejs/npmjs toolchain. or do the jqueryish development of edit->browser reload ?
> so would you say that one of the first things a htmx based project should do is handle all the error conditions ? like all the 40x and 50x ? and stuff like your modal thinggy ?
IMO yeah, but different pages and actions will (probably) want different things. For example clicking a button that makes a POST request may make more sense to have a red toast notification if it fails, however a tab that dynamically loads its content in using htmx might want a dummy placeholder saying "Sorry, try again later" or something like that. Functionality around the modals were done as and when we needed them and then expanded on over time so I don't think you need to write/know everything up front. It's honestly been a joy to use based on how simple it is once embrace server side rendering.
> how do you develop the js here ? do you setup a different nodejs/npmjs toolchain. or do the jqueryish development of edit->browser reload ?
For my projects it's just 1 or 2 JS files that are included in my base template that contain the event handlers, so it's quite old school of edit and refresh. I use Django mostly now so I can use that to collect and minify static files so it's low effort/complexity.
The only down side is for the few JS packages I do need (e.g. Select2 for nice dropdowns) I either vendor the package in (no automatic updates) or use NPM (but it's a pain). Again, depends on what you want because htmx doesn't care either way.
React forces you to think like how its designers view the world.
While alpinejs does not really interfere with your workflow. That's a huge sell for team like mine where we are working with legacy projects and devs of various levels of XP. We can get a jnr dev up and running in a week flat.
hey thanks for that. any particular opinions on hyperscript vs alpinejs ?
hyperscript is said to be "made for htmx". But alpinejs is generally more popular standalone. so im wondering about the choices here if we're starting a htmx project.
Unless you only consider the happiest path, as in "I develop on localhost with zero latency, 100% uptime, and my backend validation logic perfectly matches my frontend policies" (and probably a lot more other "if"s and "only"s).