> "Title needs (2011). Not because that's when it was written but because that's when this technique was the future." Fair play, that's a good one. You gotta take that on the chin.

🙂

Greetings, grugs! I am doing my first htmx project and have only a little frontend js experience. I have a multi-stage page in which live search in the first form makes an htmx request that returns a second form with a bunch of autofilled/dynamic values to choose from. Among these is a set of input checkboxes inside a span with id

#topics

. In this span's

onchange

attribute I call a js validation function. I also need to call the function once when the elements arrive. I don't think it matters much if it's on "load" or "afterSettle" or some other point. The easiest way I could see to do this was to handle this was with a global htmx.onLoad listener:

addEventListener('DOMContentLoaded', ()=> {
    htmx.onLoad((el)=> {
      if ((topics = el.querySelector('#topics'))) {
        validate_topics_checkboxes(el)
      }
    });
  });

Another thing I tried was to add an inline script element alongside the span in the htmx response. Surprisingly this caused the function to be called twice. In my case it's not terrible to call validation twice, but in general this seems like a bug or at least undesirable/unsupported behavior. Should I file an issue for this? Ultimately, my question is whether there is a way to do this with better locality to the DOM element. In my ideal world onload would work on all elements and I could just write

<span id="topics" onload="validate_topics_checkboxes()" onchange="validate_topics_checkboxes()">

. Sadly that's not how onload works. From the docs I see that LoB is valued by the authors, so I wonder if this is something that has been hashed out before. Thanks in advance!

oh my god

OH MY GOD

That's it, ima make a hackernews account

🙂

rather yes, mmm, i see thank u

Some of the comments on there are cringe, not gonna lie

this was a funny interaction too:

this was on the decoupling comments

I've been using HTMX with Laravel on a professional site, single dev. I replaced a Vue front-end that took a front-end dev 3 months to do in one, yes one, week with some extra hours. Some of these comments are so stupid compared to what I've experienced if you're willing to put some work into it.

Ooof

I think quite a lot of people are missing the point that htmx on it's own isn't meant to replace React, you're still allowed to use clientside JS, jQuery, Hyperscript, Alpine, whatever.js 🤦‍♂️

I never jumped on the JS frontend bandwagon because among other things, it meant putting my CMS of choice (ProcessWire) in the backseat and treating like it some API endpoint. And really, for what (at least for the type of stuff I do)? F that!

Howdy @witty-account-33479 , Since you're dynamically loading fragments into your DOM, you may have trouble with standard HTML events like

load

. You may want to check out [

hx-on

](https://htmx.org/attributes/hx-on/) which helps you to capture htmx events like

htmx:load

, etc.

https://github.com/dtao/whatever.js Hasn’t been updated in a while

What is the preferred way in htmx to update parent components. To take a trivial example, say you have a TODO list with an h2 like "TODO (6)" where the six indicates the number on the list, and then you have list items that can be edited and completed (using htmx POSTs). The server response ofc correctly updates the item itself, but now the "(6)" may be incorrect. You can use an hx-trigger, and I've taken this approach, but it never felt quite right because I now encoding knowledge of dependencies within overall page compoments into the response for a single item. Another option is to just re-render the entire page, which honestly seems simplest, but at that point htmx isn't much different from an old-school, non-htmx MPA. Am I missing anything?

Remove this from the page title? 😅

@victorious-artist-2344 It's not the page title, I edited to clarify.

(I’m only half serious) remove the count from the h2 😅

➕

Right, I forgot about that. But that suffers the same reservation I had about hx-trigger: "but it never felt quite right because I now encoding knowledge of dependencies within overall page compoments into the response for a single item." It starts to feel like procedural style jquery updates, just enacted using a different mechanism.

Hmm, it’s still declarative, no?

The element has a unique ID

I think if you don’t want full page reloads or some machinery to deal with the template code reuse in a good way… removing the count is a very real way to simplify this massively, at the cost of some UX polish

Not in any meaningful sense, no -- the virtue of being declarative is that you can understand something without knowing the details. But now where does this dependency live? I'm looking at my page, if I want to know about this dep between these parts I have to look at the server response for updating an item (or deleting or adding one). It would be very easy to miss.