https://htmx.org logo
Join Discord
Powered by
# htmx-general
  • u
    Have a div tag with htmx properties that automatically loads data from external API and renders graphs.
  • b
    Do share...
  • m
    @User @User I haven't really dug much into htmx yet, but wouldn't it be possible to trigger a request on load or click, etc. then get the data back and use it to initialize the chart? Something like this:
    Copy code
    js
  document.body.addEventListener('htmx:afterRequest
', function(evt) {
    if (evt.target.id == 'graph') {
      const data = JSON.parse(evt.detail.xhr.response);
      // Initialize chart here 
      console.log(data);
    }
  });
    Copy code
    html
<div id="graph" hx-get="/graph" hx-trigger="load"></div>
  • b
    The whole reason for using htmx (the way I see it at least) is to fetch html and swap it into the DOM. You're essentially using htmx to fetch JSON and writing JS code to handle it too. I guess it would make sense if you're already using htmx for other things, but it wouldn't be my go-to for this alone.
  • m
    Yes, I totally agree. We need server-rendered graphs 🙂
  • b
    In case anyone is interested in seeing htmx being used in the context of a CMS, I'll be on a livestream demoing and explaining 🌿 Sprig this Friday, all are welcome! https://twitter.com/craftquest_io/status/1278346380537401344
  • b
  • m
    @User Will you be going into a bit of detail on the internals, how you built it? or is it more about how to use it?
  • b
    More about how to use it. It's open-source in case you're curious, rather specific to Craft CMS though... https://github.com/putyourlightson/craft-sprig
  • m
    Thanks. I am interested in using it on my product for Joomla and WordPress, but haven't gotten to it. It'll probably be a few months, but I already starred your repo to take a look. The demos look very cool!
  • u
    Examples at htmx.org not showing server requests in bottom debug panel
  • m
    ah, I bet that's the event change!
  • m
    fix going up now
  • m
    I have the www/js marked as "ignore" in my IDE so the htmx.js in there isn't indexed, I'll fix that
  • m
    @mysterious-toddler-20573 Would there be any consideration for changing camel cased event names to a hyphenated format, or maybe add support for both? The reason I ask is because that would make it compatible with the Alpine JS event syntax which requires using event names as HTML attributes, and apparently, these are case insensitive. For example, 
    htmx:afterRequest
    doesn't work, because it would need to be 
    htmx:after-request
    . Here's an example of markup where the two scripts could be use together:
    Copy code
    html
 <div 
    x-data
    hx-get="/load"
    hx-trigger="click"
    @htmx:after-request.window="console.log($event.detail.xhr.response)"
>
    Load
</div>
    This could open up some nice possibilities.
  • m
    can you explain that a bit more? Why wouldn't @htmx:afterRequest.window work?
  • m
    iirc, boostrap uses camel case, I'm surprised that alpine wouldn't work w/ their stuff
  • m
    lemme verify
  • m
    ah, no, looks like they use dots
  • m
    :/
  • m
    this is a bit more radical, what if we switched to full colon separators and then recursively triggered events on the entire path:
    Copy code
    htmx:request:after

triggers events

htmx:request:after
htmx:request
htmx
  • m
    That would make the namespaces actually useful and trivial to use
  • m
    @User what do you think? ☝️
  • b
    Makes sense to switch to hyphens since HTML attributes are case insensitive!
  • b
    Regarding recursively triggering events, that does sound interesting...
  • b
    Thinking through the real-world use-cases...
  • m
    it makes names spaces actually name spaces...
  • m
    wanting to see all "request" related events for an element
  • m
    🤷‍♂️
  • b
    Yeah it certainly adds potential...
1...456...1146Latest