https://htmx.org logo
Join Discord
Powered by
# htmx-general
  • l
    I'd be nice if a TODO application showed this, perhaps by providing a count of the number of items.
  • g
    When you change a quantity the client, POST back to the server and load the new line back in to the browser. You should probably use an OOB swap to update the totals section at the bottom. Or, bonus points for pushing changes to specific spots using SSE.
  • m
    You can also trigger browser events from the server https://htmx.org/headers/x-hx-trigger/ and listen for the event to trigger another request to update the count. That's demoed here http://yoyo-app.beyondcritical.com/ in the 3rd example with the list + heart icons. When you click an item, that triggers an event from the browser and then the "Liked" count is updated below. These are 2 separate requests. Then when you click the "refresh" button, same thing happens (2 requests).
  • m
    You could also not have a 2nd request. Depending on how you implement it. When using hyperscript or Alpine, if you send the updated count together with the event, you could just read that and update the page. And OOB swaps allow you to do something similar.
  • m
    So, there's actually a bunch of ways to do it 🙂
  • l
    Awesome. I discussed with a colleague today about something like server-side React; where I've got a server-side DOM for a user, and based upon events, a new DOM is made, the differences are computed, and then updated elements are pushed.
  • l
    Is it possible to have a single request provide a response that updates N distinct components?
  • l
    @User With firefox 81, only the 1st heart click works.
  • m
    > Is it possible to have a single request provide a response that updates N distinct components? @User If the server response includes the output for each component, then OOB swaps let you do this.
  • m
    > @User With firefox 81, only the 1st heart click works. @User I am using Firefox Developer Edition 82.0b6 and all 3 of them are working on my end. Weird.
  • l
    @User Google Chrome 85 on Ubuntu 20.04 also has this behavior, only 1st heart is counted.
  • m
    > What about a syntax similar to the SSE connect: and swap:? That might be simpler to accomplish, and would be more consistent. @User yeah, I'm going back and forth on this
  • m
    I like what I have, it's only 300 bytes in implementation so far so not awful
  • m
    and it is more general, but is it too much?
  • m
    🤔
  • m
    this also makes me think:
  • m
  • m
    @User Is there a reason for processing response headers right after a request, rather than after swap? https://github.com/bigskysoftware/htmx/blob/27d6fdd1e3e3d3cb3f11e8e2f97322ffd17ba129/dist/htmx.js#L1729 In the case of events if you want to do something with the swapped HTML as a result of the HX-Trigger, it doesn't look like it's possible at the moment.
  • g
    @mysterious-toddler-20573 - I was just throwing out another option, because it sounded like the lexer was giving you some trouble. But, 300 bytes sound pretty compact to me — I’ll be curious to see it when you’re settled.
  • g
    Will there be any chance to reuse the lexer in other parts of the library?
  • m
    @User no reason other than that's when I did it in intercooler.js but I can see an argument for doing it after the swap...
  • m
    @User yeah, i did the lexing a few different ways and finally struck on a clean way. I can adopt the lexer in the areas we do poor-mans parsing with split() right now and clean things up a bit. Still chewing on it.
  • g
    Nice!
  • m
    @User what if we offered a few different headers: 
    HX-Trigger
    , 
    HX-Trigger-After-Swap
    , 
    HX-Trigger-After-Settle
    etc.
  • m
    That would be perfect! Right now I am solving it using an eventQueue that I later read on afterSwap.
  • m
    '> tfw you should be working on work but you are working on an obscure open source project instead
  • m
    I know the feeling, it's exactly what I am doing as well with this Yoyo thing
  • m
    So basically, this is all your fault 😉
  • l
    @mysterious-toddler-20573 Well, I can't cheer you on enough. Data scientists really need ways to better interact with browser front-ends without having to become Javascript experts.
  • m
1...495051...1146Latest