https://htmx.org logo
Powered by
# htmx-general
  • h
    for the same resource or for a block of links?
  • h
    if it's a block - wouldn't the preload only get triggered on mousedown?
  • g
    i thought it was on hover
  • h
    docs say: "preload="mousedown" (DEFAULT)" - but assuming I updated to be mousedown anyway
  • g
    then i can't think of anything
  • h
    yeah me neither
  • h
    ok I'm going to set that then 🙂
  • h
    does demo.htmx.com live in the repo?
  • h
    I'm trying to update it to allow setting a custom status code on the template return
  • h
  • h
    Copy code
    var status = elt.getAttribute("status") || '204';
                    MockRequests.setDynamicMockUrlResponse(elt.getAttribute("url"),
                        {dynamicResponseModFn:
                                function(request, response, parameters) {
                                    log("demo:request", "A mock request was made: ", request, response, parameters)
                                    return interpolate(elt.innerHTML, { ...parameters, ...Object.fromEntries(new URLSearchParams(request)) });
                                },
                            responseProperties: {
                                headers: {status: status},
                                status: status,
                                responseText: "fake",
                            },
                            delay: delay,
                            usePathnameForAllQueries: true});
                }
  • h
    should work to set the status on the mocked response, but I can't seem to get any kind of override into the response
  • h
  • h
    I think I might be misunderstanding what the preload extension does - it's not actually using anything w/ htmx's cache is it? it's just using the browser cache?
  • h
    so it's expected that if I use mouseover as the preload method, I'll get two network events? One for the preload and a second for the click?
  • h
    and that if it's not a cached response in my browser it's probably my headers need more caching
  • s
    I'm coming from an Angular background. When doing forms validation Angular includes some special states (untouched, dirty, etc) that are useful for holding off on displaying errors until the user has unfocused from a field. (https://angular.io/api/forms/NgControlStatus#css-classes-applied) Is there anything equivalent with htmx? If not I'm considering writing an extension and wanted to gauge interest. It would be good to have some sort of common way to include those details when triggering validation.
  • p
    It’s an interesting debate. I don’t think SPA by itself a mistake, it works nicely if you want your web app to behave like a native app(especially if you already have a desktop/mobile app first and then going to the web), which is a valid use case for some web apps.
  • p
    Problem is, it’s been abused. More often you don’t need a SPA, and traditional MPA works well for most use cases. I hope HTMX becomes more popular and bring the web back to sanity, aka what it was meant to be.
  • w
    Hi! I'm having an issue with nested click events - that is when a child element is clicked, the parent event is also triggered - there must be a way to solve this? Example code:
    Copy code
    <div hx-get="foo"> 
    some content
    <div hx-get="bar">
        some content
    </div>
</div>
    clicking the inner element triggers requests to both "bar" AND "foo". Any ideas?
  • w
    Ah 
    hx-target="click consume"
    on the inner element! Makes sense 🙂
  • c
    you could also experiment with trigger filters htmx.org/docs/#trigger-filters so for example if you gave each div an id, then on the outer div you could ignore the trigger by saying something like ``hx-get="foo" hx-trigger="click[id!=idofbardiv]"``
  • w
    Handy!
  • m
    we support html 5 validations but nothing beyond that, an extension would definitely be interesting!
  • g
  • s
    Actually I might be overthinking it. It could be as simple as making the hx-trigger 'onblur' for initial render then 'onchange' for subsequent ones. I'll post what I learn...
  • j
    Noticed this week's edition is missing from the feeds, or at least the ATOM one.
  • g
    Yes and yes. We're just using the browser cache. The htmx trigger/load/swap code is very complex and it doesn't give us a place to insert a lot of code. This setup works pretty well, but you do have to be careful about your network headers. @mysterious-toddler-20573 - imagine a preload plugin that could split the trigger and swap into two separate steps. So, trigger on 
    mousedown
    and swap on 
    mouseup
    . It would be the holy grail of web performance. All I need is access to the 
    htmx.swap()
    function from the internalAPI...
  • h
    yeah that's how I assumed it would work
  • h
    well
1...665666667...1146Latest