https://htmx.org logo
Powered by
# htmx-general
  • m
    It should but let’s find out
  • a
    I think I'm asking the wrong question. I'm using the path-deps plugin (yeah, that's how I roll) and all the hx-indicator's of the child elements light up like a christmas tree if the hx-get on a parent element get's triggered via a path dependency. I fudged it before by specifying hx-indicator="none" on the parent element .. but now I want to do it the right way. I'll grind on it a bit, I'm sure I'll figure it out
  • a
    Got it sorted 👍
  • w
    👋 I made an announcement today about some funding I'm getting to work on a Clojure web framework called Biff. In the next release I'm switching it to HTMX! Hopefully that'll be out after a few more weeks. See the three paragraphs after "What's next for Biff" for the part about HTMX: https://biffweb.com/p/sponsorships/. I've finished the example/template project already, see https://github.com/jacobobryant/biff/blob/dev/example/src/com/example/feat/app.clj for the HTMX bits. It's super basic; just a text field + a chatroom with web sockets.
  • m
    awesome!
  • p
    Hey I get this error on a page and im not able to click any htmx links at that page
  • p
    It was working before, not sure how i broke it
  • h
    When doing for instance an hx-post, that request can fail (due to input validation for instance). in that case I think I don't want to replace some element in the DOM with the response. How do you sort this kind of situation? Return the original HTML?
  • h
    what return code is the server giving?
  • h
  • h
    Whatever I might want. If the http status codes mean something to htmx I can arrange them
  • h
    the longer form answer is: if something fails for validation after you send it out you are either going to want to replace content from the server (htmx normal behavior) or trigger some kind of client side event
  • h
    if you trigger client side event you'd either replace no content (204 response) or return new content AND do a client side event which is normal behavior
  • h
    OR you'd have the sever return a 4xx response, which would never replace content
  • h
    Ah, got it. I think I'll go with the latter. Appreciate it 👍
  • h
    one thing I"m not sure about is how you'd have 4xx event handler be local vs global
  • h
    because I"m assuming you'd want to trigger some kind of validation for JUST that form
  • h
    but I think the htmx event (https://htmx.org/events/#htmx:responseError) might be global?
  • h
    you could get around that by checking detail.elt, which is the element that triggered the request
  • h
    For context, I'm a backend developer that hasn't written any serious frontend code since the early 2000's. I'm trying to see how far I can go with htmx in a toy project but sticking only to HTML/CSS. I would rather ignore any JS events.
  • h
    I think either the 4xx, or a 2xx with the original HTML plus an error message would work for what I'm trying to do atm.
  • h
    I think you want the 2xx with an error message
  • h
    most frameworks (django/rails/larvel) do it that way
  • h
    Maybe... And it's probably more in the "zen" of htmx, if I understand it correctly 🤔
  • h
    yeah
  • h
    it's not always the right approach for validation - client side/pre submit there's normally a validate step
  • h
    but the general zen is once it hits the server, the response is html
  • h
    you can use client side events too - super powerful: https://htmx.org/headers/hx-trigger/
  • h
    but that's fundamentally javascript
  • m
    my guess is a javascript library is hijacking the history element
1...590591592...1146Latest