4 ms·

The real power of HTMX and Web Components is that Web Components self-initialize when they get attached to the DOM, so they are easy to AJAX in. This was always

The real power of HTMX and Web Components is that Web Components self-initialize when they get attached to the DOM, so they are easy to AJAX in. This was always a PITA in the jQuery world since you would have to hunt down the new interactive elements and run a library's init function on them.

boringuser2 3y ago
I haven't seen the term "AJAX" used in years. Very bad sign both for the project and people mentioning it.
- worthless-trash 3y ago
  Using a term is not a bad sign.
  - boringuser2 3y ago
    It means your knowledge is likely quite dated.
    - linkdd 3y ago
      AJAX literally is "async request from the client to the server". https://en.wikipedia.org/wiki/Ajax_(programming)#Technologies https://en.wikipedia.org/wiki/Ajax_(programming)#Technologie... XML (the X in AJAX) is not even necessary as JSON came in. Any React/Vue/Angular/... client application using `fetch` to make a request, is making an AJAX request. Just because you haven't seen the term in a long time does not mean it is outdated.
hellcow 3y ago
This is the exact use-case I found for them, and it’s terrific. I define any tag, e.g. <my-modal>, put normal HTML within it as if it were just a div, and then I can define the callbacks (like adding/cleaning up listeners) and custom attributes in a tiny bit of JS.
lelanthran 3y ago
> The real power of HTMX and Web Components is that Web Components self-initialize when they get attached to the DOM, I've run into some problems with the Custom Element lifecycle, though. Not sure how to solve them, because `connectedCallback` is the wrong place for my custom code. The odds are I am doing it wrong (or have a fundamental misunderstanding!) Basically, lets say I have two custom elements: A and B. All Bs are a descendant (even if not direct) of an A. Each A grabs all B children and copies the data out of a specified child of the B, then uses it.[1] When the connectedCallback for A is executed, the Bs are not yet connected and thus don't show up in a call to querySelector. I've (sort of) worked around this by having each B, when connected, find the closest A ancestor, and add itself to an array field of that ancestor. A's connectedCallback performs a setInterval with ever-increasing delays until some specific maximum (I use 10ms). The setInterval just redisplays with whatever labels are in the array. Now, this is probably a stupid way of doing this, and I believe a better way is to use MutationObserver, which I will probably switch to at some point. However, my point is still: the life-cycle did not offer me some way to hook into A only when all the children are attached to the DOM. [1] A practical example of this would be tabbed-containers. The <tab-container> shouldn't hold the labels for each <tab-item>, it should get the labels from the <tab-item> itself.
- have_faith 3y ago
  I think your workaround is probably the most preferable of the options. I've worked with mutation observers a lot and I wouldn't want to rely on them for anything that didn't have a simpler mechanism to achieve the same thing. In "regular" frameworks, this problem would be expressed as state that is owned by A, that B's contribute to. Maybe by calling a function passed down to them, or by updating a shared store. It's a big shortcoming that composition of web components is limited to string attributes unless you use some sort of framework to mediate things.
- AndrewHampton 3y ago
  Another option would be for the B to dispatch a `CustomEvent` on itself. That event will bubble up the DOM until it hits A. A would then need an event listener that would probably stop propagation and do whatever bookkeeping is necessary.

boringuser2 3y ago

I haven't seen the term "AJAX" used in years. Very bad sign both for the project and people mentioning it.

worthless-trash 3y ago
Using a term is not a bad sign.
- boringuser2 3y ago
  It means your knowledge is likely quite dated.
  - linkdd 3y ago
    AJAX literally is "async request from the client to the server". https://en.wikipedia.org/wiki/Ajax_(programming)#Technologies https://en.wikipedia.org/wiki/Ajax_(programming)#Technologie... XML (the X in AJAX) is not even necessary as JSON came in. Any React/Vue/Angular/... client application using `fetch` to make a request, is making an AJAX request. Just because you haven't seen the term in a long time does not mean it is outdated.

hellcow 3y ago

This is the exact use-case I found for them, and it’s terrific. I define any tag, e.g. <my-modal>, put normal HTML within it as if it were just a div, and then I can define the callbacks (like adding/cleaning up listeners) and custom attributes in a tiny bit of JS.

lelanthran 3y ago

> The real power of HTMX and Web Components is that Web Components self-initialize when they get attached to the DOM, I've run into some problems with the Custom Element lifecycle, though. Not sure how to solve them, because `connectedCallback` is the wrong place for my custom code. The odds are I am doing it wrong (or have a fundamental misunderstanding!) Basically, lets say I have two custom elements: A and B. All Bs are a descendant (even if not direct) of an A. Each A grabs all B children and copies the data out of a specified child of the B, then uses it.[1] When the connectedCallback for A is executed, the Bs are not yet connected and thus don't show up in a call to querySelector. I've (sort of) worked around this by having each B, when connected, find the closest A ancestor, and add itself to an array field of that ancestor. A's connectedCallback performs a setInterval with ever-increasing delays until some specific maximum (I use 10ms). The setInterval just redisplays with whatever labels are in the array. Now, this is probably a stupid way of doing this, and I believe a better way is to use MutationObserver, which I will probably switch to at some point. However, my point is still: the life-cycle did not offer me some way to hook into A only when all the children are attached to the DOM. [1] A practical example of this would be tabbed-containers. The <tab-container> shouldn't hold the labels for each <tab-item>, it should get the labels from the <tab-item> itself.

have_faith 3y ago
I think your workaround is probably the most preferable of the options. I've worked with mutation observers a lot and I wouldn't want to rely on them for anything that didn't have a simpler mechanism to achieve the same thing. In "regular" frameworks, this problem would be expressed as state that is owned by A, that B's contribute to. Maybe by calling a function passed down to them, or by updating a shared store. It's a big shortcoming that composition of web components is limited to string attributes unless you use some sort of framework to mediate things.
AndrewHampton 3y ago
Another option would be for the B to dispatch a `CustomEvent` on itself. That event will bubble up the DOM until it hits A. A would then need an event listener that would probably stop propagation and do whatever bookkeeping is necessary.