https://htmx.org logo
Powered by
# htmx-general
  • m
    I have an example in intercooler that could be updated for htmx using hyperscript or vanillajs https://intercoolerjs.org/examples/bootstrap_confirm.html
  • b
    Thanks.
  • m
  • m
    Has anyone used stimulus js?
  • m
    I used stimulus for a bit in an older rails app, and then I added 
    ic-action
    to intercooler to use instead. It was (as of 2.0 anyway https://stimulus.hotwired.dev/) still MVC oriented and I wanted something event-oriented. With htmx, that got split out to hyperscript: https://hyperscript.org which is geared towards gluing events together rather than providing a front end MVC framework. Closer to Alpine, but not reactive, and with the focus on front end expressiveness.
  • m
    so htmx + hyperscript would be the equivalent to turbo + stimulus as far as dhh's and my respective visions for how web development should work
  • m
    It looks like 3.0 continues that same general flavor w/ stimulus
  • m
    impressive app created in a hackathon by Khalid and some JetBrains folks, using htmx on top of .net: https://twitter.com/buhakmeh/status/1441471637434474498
  • m
    sometimes it all comes together friends: https://twitter.com/htmx_org/status/1441906224010645504
  • m
    I rewrote the intercoolerjs example in htmx and hyperscript https://htmx.org/examples/confirm/
  • b
    Thanks for this.
  • b
    Do you guys return a 200, or an error code when form validation fails on the server? Some people suggest using 422 "unprocessable entity" for "semantic errors" (while 400 "bad request" for "syntax errors"). I wanted to try to follow this convention, but htmx by default does not swap anything when receiving a response between 4xx/5xx. So it does not render my inline form errors. What is your take on this?
  • m
    hmmm
  • m
    @User, thoughts?
  • g
    why does it not swap on 4xx?
  • m
    because error
  • g
    error message?
  • g
    browsers show 404 pages, shouldn't htmx too
  • m
    just jamming a 404 message into whatever the target was seems... less than ideal
  • m
    I have considered making this pluggable
  • m
    so you can open up response codes to be rendered properly
  • g
    the server can send an appropriate error message for the target
  • m
    I think that's a good, backwards compatible mechanism to handle this
  • g
    idk, "just add an option" is rarely the correct answer
  • m
    it's a callback, totally different
  • m
    😑
  • g
    can one do this with the existing extension mechanisms
  • m
    no
  • m
    allows you to listend for the 
    htmx:shouldSwap
    event and override the default behavior
  • m
    Copy code
    on htmx:shouldSwap(xhr)
    if the xhr's status is 422
       set shouldSwap of the event's detail to true
1...370371372...1146Latest