RE: CORS, just depends on your solution. e.g. https://gist.github.com/wiverson/66b73829f4a517861fca2c8be19549af

This may be a silly question but, is there a way to target a specific div on the page that is being swapped in with HTMX? Like used to be the case with jQuery like this: $( "#result" ).load( "ajax/test.html #container" );

I used hx-target already but that only seems to work on the page where the event is triggered rather than swapping in the element with the same selector that exist on the page that is being targeted.

> page being targeted can you explain that more? You have multiple tabs open here?

Well, simply put I have two pages. Page 1 and Page 2, they are both using the same PHP template (defined in index.php) this template consists of a header (containing the menu), a content area and a footer. the content area has a div with the class of "replacer" that surounds the content. As such, this div with that specific class is present on both Page 1 and Page 2. In Page 1 I have a button which triggers the HTMX ajax request. The effect I want to achieve is that, not the whole page (with the top menu and the footer) gets loaded in but just the "replacer" div gets loaded in and as such essentially swaps the content of Page 1 with just the content of Page 2 (since the menu and footer are already present on Page 1 and as such don't need to be loaded in), as such, I'm wondering whether there is a way to target only a specific element on the page (or file) being swapped in rather than the whole page/file (as demonstrated in the jQuery ajax example I provided in my previous post).

hey wondering how you would temporarily change a button to display a checkmark if a transaction was successful (say a form POST), but fade back to the original button without needing to press "restart" or reloading the page.

Doesn't a straight

hx-post

with a

hx-target

to

#replacer

handle this? https://htmx.org/attributes/hx-target/

I thought it would but apparently it doesn't. What that does is indeed swap out the target div with the innerHTML of the url being fetched but instead of getting only the specific div specified in hx-target, the content being swapped in is the entire page (Page 2 in this instance) as I have two footers and two headers when the request completes...

Somebody can correct me if I'm wrong (because I never used it) but it seems that https://htmx.org/attributes/hx-select/ is what you're looking for.

The equivalent of

js
$( "#result" ).load( "ajax/test.html #container" );

is

html
  <button hx-get="ajax/test.html" hx-select="#containter" hx-target="#result">Get It</button>

yes, hx-select is the missing piece here

Thanks! I knew this was a silly question... (I must have glazed over the hx-select in the docs), Still, I'm glad that I know now. Thanks again!

No prob! Thanks for checking out htmx 🍻

I'm currently struggling with a stange behaviour. I've got a fragment which is returned by a django view and is loaded with hx-get=... hx-trigger="load". On that fragment, if i try to use hx-trigger="load" again, the handler is triggered many times (26 in my case). Any ideas how to debug this? Basically I wanna implement the sortable example from the docs, but the sortable list is not there at the first load, it gets pulled later and i wanna initialize the sortable javascript if the fragment is ready.

It sounds like it's doing something like a load poll

maybe add an

delay:2s

to delay the load a bit so you can see what is happening?

I delayed the load of the inner fragment, it then loads it only twice. But i think i f*cked something up during refactoring. I'll get back to it if the problem persists.

👍

someone passed this along and asked what my take was, my comment: > broadly positive. I don't like the complexity of modern build systems, so anything that simplifies that seems like a good thing. I don't know how I feel about source maps, technically, but I doubt I'll be using them very much. I tend to just shift-reload to clear the caches when necessary. > > Stepping back, you know how I feel about writing javascript in general for web apps: it should be limited to improving front end experiences rather than adopted as a network architecture. So my hope is that javascript shrinks as an overall component of web applications over times, which makes improvements in the tool chain less important. > > I'd also note that by inlining behaviors in the DOM, as with htmx and hyperscript, this problem largely goes away: the code and behavior is all at the use spot, so it is naturally lazily optimized. > > Still, good article, and I appreciated DHH continuing to push for much needed simplicity in the web development world. what's your take?

javascript build systems are best seen as polyfills. I don't like the idea of using bundlers to add non-standard features to JS. > I'd also note that by inlining behaviors in the DOM, as with htmx and hyperscript, this problem largely goes away We still have the issue of a single change invalidating the whole file. > I tend to just shift-reload to clear the caches when necessary. Cache busting is for the user, not the developer. That said, could the same effect not be achieved with etags?

> Cache busting is for the user good point, I guess I have never changed my javascript quickly enough for this to matter.

I have always assumed that browsers cache compiled javascript locally, and don't recompile when they see the same source, is that a reasonable assumption?

the cache busting thing seems to argue for a better cache busting mechanism, doesn't it. Yes, I remember etags being mentioned as the way to do this, but haven't looked at it in a while. But that does get at the core problem I've always had with this stuff: feels pretty hacky

> We still have the issue of a single change invalidating the whole file. tell me more

> Most popular browsers implement some form of code caching, -- https://v8.dev/blog/code-caching-for-devs

🤌

have considered a cache for hyperscript before, seems like a fun project to nuke unsuspecting users memory profile

well, hacky is a synonym for nontrivial, and cache invalidation is one of the two hard problems, so...

Right, but using query params seems... well... there are three hard problems in CS.