https://htmx.org logo
Join Discord
Powered by
# htmx-general
  • g
    Ok. So the internal htmx code would use a "custom" 
    onload
    handler that called other extensions, and handled response headers.
  • g
    By default, I think it just caches based on the URL. But you can use the HTTP 
    Vary
    Header to change that. As an example, I usually use 
    Vary:Authentication
  • m
    > As discussed above, caching servers will by default match future requests only to requests with exactly the same headers and header values.
  • m
  • m
  • g
    Hmmmm.. So ALL the headers would need to match?
  • m
    it's dumb how little I know about HTTP after nearly 25 years of this stuff
  • m
    Looks like it, but that's what we will get, so it's all good
  • m
    This is a good change
  • g
    Yes, this is a good change.
  • m
    opens up some interesting possibilities in hyperscript too
  • g
    Since htmx includes so much information in the headers, it may cause more cache misses than we intend. I think we'll need to experiment.
  • m
    good point
  • g
    Yes. All of these features would be fantastic for hyperscript to access.
  • g
    Along these lines #255 - "Publish swap() function to external scripts" seems like a logical next step.
  • s
    I have not though about this yet. But this could be a drawback in the long run. Up to now my small applications does not rely on those headers, maybe htmx should not send them by default, only if enabled explicitly. But only if these headers will cause http caches to not cache these requests.
  • m
    OK, I have made a few changes: * I refactored and cleaned up the signatures for ajax handling * There is now an 
    htmx.ajax
    API method (still need to document it) * I removed some headers that would vary between requests. They were speculative and not a crux feature, and people can add then back via hyperscript or whatever if they want them
  • m
    @User for your use case, I think you want something like this:
    Copy code
    js
  htmx.ajax("GET", whateverThePathIs, 
            {source:theElement, 
             handler:function(){/* do nothing, allow response to cache */ })
  • m
    For someone who wants to issue a request manually and target element #foo, they can say:
    Copy code
    js
  htmx.ajax("GET", "/whatever", "#foo")
  • m
  • g
    This will be awesome. Where should I look for it, dev branch?
  • g
    I like the idea of limiting the headers that are sent by default, then possibly adding them back in (via extensions?) for those who need them.
  • m
    dev branch
  • u
    Here after the recent launch of hot-wire. I fundamentally see a lot of value in projects like HTMX and Hot-wire both, but HTMX feels more complete for my needs I am trying to build a demo app which behaves a bit like product hunt (in terms of interactivity) with HTMX and see how far I can get. Will post my progress and issues here 🙂
  • u
    What is the best way to disable a button when a request is in progress?
  • u
    Also related to this. Is it possible to only scope the 
    htmx-request
    class to the current element parent. Otherwise if I have multiple loading elements on a page, they all start spinning
  • g
    Hey @User -- welcome to the chat! htmx generates tons of events during an xhr request. You can listen to these from plain Javascript (or Hyperscript) to toggle properties on your buttons.
  • g
    For submit buttons, I also like having two separate components on the page -- a real button that is visible until clicked, and a "disabled" one with different text and a spinner that starts off invisible. When the user clicks the real button, use Javascript to hide it and show the disabled one.
  • g
    Try listening for htmx:beforeRequest [https://htmx.org/events/#htmx:beforeRequest]
  • s
    @User thank you for your link to beforeRequest. Since it is a very common use-case it would great if it would be possible to disable a button and show a spinner without using JS.
1...110111112...1146Latest