rewritten to use the existing

htmx:beforeSwap

event

on htmx:beforeSwap(xhr)
    if the xhr's status is 422
       set shouldSwap of the event's detail to true

open to suggestions for name changes for

shouldSwap

I like this because it lets you handle 404s on your own too:

on htmx:beforeSwap(xhr)
    if the xhr's status is 404
       call show404Message(xhr.response)

i've used htmx in my new weird website. it's a game where you bet fake money on the outcomes of car auctions from bringatrailer.com. i'm mostly using hx-boosting but i'd like to hear suggestions on where else to leverage htmx or general suggestions. check it out at https://0.team

it's django + htmx. there's some jquery but i'm looking to move to only alpine + htmx

I don’t know what’s the appropriate technical solution for errors handling, but a clear mechanism feels instrumental to me. Errors are part of the application lifecycle. They are expressing behaviors (mostly bad/incorrect behaviors). And it is not safe to think that any error can be left silent. You almost always have to deal with an error, and even more at the UI layer, to give information to the end-user. I am trying to think with hypermedia (and HATEOAS) in mind, and to me, having an error should definitely be treated as any other behavior. So when encountered, the client should be presented with information (flash message, inline error message), and potentially an instruction for what can be done next (retry, accept the error, try the action differently...). But as a user, if I interact with the application and "nothing happens" because of an error, I’ll be frustrated. HTTP deals natively with errors through error codes, but I think the browser does not alter the UI (aka HTML) when receiving an error code. It is up to the server to introduce an error message in the response body to inform the user (with potentially a goto action). So I don’t really understand why sending back an error code between 4xx/5xx would prevent htmx from dealing with the swap by default. I agree with @User and this shouldn’t be fixed as an "addon", but it should be part of the core design of htmx. (that’s my take without knowing the technical details and limitations)

yes, I'm in agreement, I think the change that I've made addresses this problem in the core, using an existing event, and gives htmx users a clean opportunity to handle response codes however they would like

Can you please point more precisely to this change? Do you have a commit nb maybe?

And another unrelated question, how often do you release a new version of htmx off master? (or maybe there is a way to import the "master" version from CDN?). Thanks

I usually release a new version of htmx about every month and a half right now

I'm not completely done with the change, there are a few more things I'd like to add

I have one more change I'd like to get in for htmx 1.6

I will try very hard to get the 1.6 release out this week

Thanks for your work. I really look forward to the next version

Hi! I don't know where I'll ask this since I've been googling for hours now haha. Why is this function not working? ( I'm following the docs )

But when I go to console, it says the function is undefined

I don't know if I'm missing something syntax wise or the solution is pretty obvious, help 😦

The cdn is on top

Complete code. Hope someone can help, I'm really liking using this library, having fun with it. This is the first major roadblock I encountered. I can't seem to make functions work

Hi! I'm new to HTMX, and haven't done web dev in years, so pls forgive my ignorance 😁. Now, I have a question: I have a with several options. For certain options, I'd like to show another select to further limit the selection.

Is it possible to only perform an hx-get on certain option values?

Hi there, in meetings for a bit, but will try to help this afternoon

I don't believe so, unfortunately. There aren't any events triggered on the options directly, iirc

you could use a filter expression in the trigger on the select though

But how would I filter on the selected value?

Hyperscript has to wait for the document to load, whereas JS script elements can run as soon as they are seen. So, your JS will run before any hyperscript. I found that calling

_hyperscript.processNode(document)

at the start of your script works

something like this:

html
  <script type='text/javascript'>
     function verifySelect() {
        var select = htmx.find("#mySelect");
        if(select.value == "foo" || select.value = ... ) {
           return true;
        }
     }
  </script>
  <select id="mySelect" hx-trigger='change[verifySelect()]' ...>
    ...
   </select>

(code written in discord, might be very wrong 🙂