https://htmx.org logo
Powered by
# htmx-general
  • m
  • m
    @User I guess the problem with getting the triggerer on an example like this one in events happening after swap is that it's no longer even available on the page. Maybe this is an obscure case that doesn't merit making changes to the code? I have it working by reading the request header ID.
  • m
    mmm, yes
  • m
    So 'elt' is gone at that point.
  • m
    I have some logic for dealing with this situation where I snapshot the hierarchy before a swap, and then after a swap, if the element is no longer in the DOM, I trigger the event on both the now-gone element as well as the closest parent still in the DOM, to simulate bubbling across the swap boundary. Ugly.
  • m
    Sometimes it takes a tough man to make a tender chicken
  • m
    Ok. I am using this to read an attribute from the element, not for events. So I'll stick with using the header id for now.
  • m
    roger
  • m
    Thanks for the insights though 🙂
  • m
    😑
  • m
    events across DOM mutations are not my favorite things to work on or think about
  • m
    Btw, Alpine V3 has it's own "morph" plugin now. I haven't tested anything there yet, but I'd like to try it with htmx at some point https://github.com/alpinejs/alpine/blob/main/packages/morph/src/morph.js The benefit there would be to be able to replace entire Alpine components with htmx without losing Alpine data/states after swap.
  • m
    👍
  • f
    Hey all, What is the best way to handle server-side form validation (or other processing) errors when using htmx? Normally, I'd return a json with a response code of 400 and display the errors, but this doesn't work well. Is it best to send a new template for the form back with the errors displayed? My challenge there is that when the form works well, the htmx doesn't change the form (it updates a table) so the handling is quite different in an error case.
  • g
    You can work it several ways, but I'd say "yes." If the form is incorrect, then return the HTML for the form along with inline error messages about what to fix.
  • g
    If the form is successful, you might try sending back an 
    hx-redirect
    header that will send the client to the next correct spot.
  • m
    what server side tech are you using?
  • m
    in rails you can update a model, verify it and then rerender a form with errors automatically populated from the model
  • f
    Which makes sense, but when the form has 
    hx-target
    set, the returned html wouldn't necessarily replace the 
    form
    (nor would I want it to), and returning the table that is normally returned is fine but has no new data so is a bit pointless.
  • f
    I'll take a look at 
    hx-redirect
  • f
    Django
  • m
    Ah, OK
  • m
    I see what you are saying
  • m
    So two options:
  • m
    the first is to just target the outer HTML, maybe use hx-boost and just rerender the whole thing.
  • m
    the second is to use the 
    HX-Redirect
    header to do a client side redirect
  • m
    the third is to use out of band response content
  • g
    Yeah, there are lots of things to consider. If you do need to replace the form, you might consider using 
    hx-swap-oob
    to force the response into the original form element.
  • g
    That's three. Three options.
  • m
    like I said
1...299300301...1146Latest