https://htmx.org logo
Join Discord
Powered by
# htmx-general
  • m
    @User You can also use the 
    onclick
    attribute to disable the button, then replace it with a non-disabled version on swap. Demo here https://codepen.io/jreviews/pen/ExgbvvW
  • g
    Hey @User -- good point. A declarative way of handling this would be pretty nice. With Hyperscript, I think we can get close. Here's one way it might work:
    Copy code
    html
<button hx-post="/server" _="on htmx:beforeRequest take .hidden from .buttons">Do The Thing</button>
<button class="hidden">I'm Doing the Thing...</button>
  • g
    According to @mysterious-toddler-20573, Hyperscript is really meant to be the companion to htmx, and it fills in a lot of these client-side rules really nicely -- and "almost" declaratively.
  • m
    the 
    htmx-request
    class should only be added to the element making the request, unless you use the 
    hx-indicator
    attribute: https://htmx.org/docs/#indicators
  • m
    On the disabled concept, we don't currently have anything built in, but we probably should.
  • m
    maybe something like
    Copy code
    js
   <div hx-post="/example" hx-trigger="click serial">
     Only One Request At A Time Please
   </div>
  • g
    Sounds good. Perhaps with a corresponding css class that we could target?
  • g
    Or, could this be something inherited down through all DOM nodes? 
    <body hx-serial="true">
  • a
    Quick question: what is the equivalent htmx event/logic to the 
    pushUrl.ic(evt, target, data)
    event we have in Intercooler, to trap a url push?
  • a
    It looks like 
    htmx:beforeHistorySave
    ?
  • a
    Hmmm no I think that is equivalent to 
    beforeHistorySnapshot.ic(evt, target)
    instead?
  • a
    OH - I found this on line 2036 in the source: 
    triggerEvent(getDocument().body, 'htmx:pushedIntoHistory', {path:pathToPush});
    Seems like this would be the equivalent event to Intercooler's 
    pushUrl.ic(evt, target, data)
    event, correct? Just not documented yet?
  • a
    Another question: given that you're using the 
    path-deps
    extension, what is the equivalent action/mechanism for programatically triggering refreshes on a path, a la 
    Intercooler.refresh(eltOrPath)
    ?
  • s
    "take .hidden from .button" even more readable than python. And this means a lot :-) Nevertheless I think it could be even simpler, more declarative. Why not "disable all input elements of this snippet and show an hourglass above it?" like 
    hx-disable-and-hourglass
    . Of course I could write a method like this myself, but the big benefit would be a standardization.
  • g
    Yes.. Hyperscript is awesome, and is a great way to get things done NOW, while we work out what SHOULD be in htmx. I'll bet this kind of feature is even doable as an extension. @mysterious-toddler-20573 replied above with some ideas on how we might accomplish this, too.
  • g
    I guess there's two components: 1) css styling and 2) locking out other ajax methods while one is "in flight"
  • g
    I'm nearly certain we could accomplish the styling now (via Javascript/Hyperscript or an extension). Locking out additional requests would take some kind of extra work on the core library.
  • g
    For 
    hx-disable-and-hourglass
    we'd probably add some kind of additional css class (see https://htmx.org/reference/#classes) and let developers write their own stylesheets to use it.
  • m
    I need to think more about this @salmon-xylophone-28580, it's a good problem to bring up and we should support it better OOTB, but I just need to think about the cleanest syntax
  • m
    Unfortunately it looks like we don't really include that right now. It should probably be part of the extension....
  • m
    Are you interested in working on that with me?
  • a
    Sure 👍
  • a
    I’ve had a good look through a large app that uses Intercooler extensively... and as far as I can tell the only bit I can’t do with htmx atm, is to call refresh on a path, so I’m interested in getting that working in htmx 🙂
  • g
    Hey @mysterious-toddler-20573 -- this may be a bad idea, but maybe it starts the discussion. What if ALL transactional requests (POST, PUT, DELETE) were single threaded.. at least per element. That is, if any element has already triggered a transactional ajax request, it's automatically locked until the request completes.
  • g
    This might be easy to do on the element level. Or, we might even look into locking based on the URL across all elements.
  • g
    This is still off-the-cuff, so there could be some huge gotchas with this approach, but that could let us implement this feature (or something like it) without any additional syntax.
  • m
    We currently only allow one request per element, but we queue up a second request if another event comes in.
  • m
    The behavior should probably be element-type dependent
  • m
    buttons: you probably don't want another request to fire
  • m
    other inputs, you probably do
1...111112113...1146Latest