One thing that "mature" libraries have is a consensus on the best way to do things. And that only comes from lots of people trying lots of weird patterns, until one of them clicks.

This is true, or even just a few more examples of the edge case type things as they emerge. I'm using it for some pretty simple stuff, but everytime I think it's simple it gets more complicated so I'm happy to share what I can after.. overall htmx makes 95% of things easier, it's just sorting out that last 5%.

For the

context object

referred to here: https://htmx.org/api/#ajax any idea how that has to be formed?

It's just JSON

javascript
{
  source: "the source element of the request",
  event: "an event that 'triggered' the request",
  handler: "a callback that will handle the response HTML",
  target: "the target to swap the response into",
  values: "values to submit with the request headers"
}

Does that make sense?

Ah! Okay. Json is perfect.

Or, more specifically, it's a javascript object that you're passing in to the

htmx.ajax

function. So just define it using

{}

and you'll be good.

Although when you use that then you have to specifically indicate the

target

in the object.

I'm also assuming I have to "stringify" everything and can't just include a javascript object within the context then right?

I haven't used this, so double check my assumptions. I think it's just an "object" and not a string. From the docs, I think you just put the native value in there without stringifying it.

Okay, looks good, I think I've got a fair bit of this working between cobbling together

hx-include

and passing along a few variables. One thing I've noticed, is that I'm setting

source

in the

htmx.ajax

call, and the

source

isn't being turned into the

HX-Trigger

or

HX-Trigger-Name

as I'd expect. Am I using that wrong?

(that said

target

gets passed along perfectly)

I may be mis-reading you, but

hx-trigger

is either an attribute on a page element, or a header in your server response. The one I was talking about is the response header. I'm not sure if that is handled in

htmx.ajax()

or if it's somewhere deeper in the library.

@mysterious-toddler-20573 - can you illuminate this for us?

Maybe I didn't explain it properly I'm using:

htmx.ajax('GET', 'url', {target: "#target-container", source: "source-identifier"})

and submitting it. htmx turns the

target

into a

HX-Target

header, but the

source

just seems to disappear whereas I was expecting (hoping) it would get turned into the

HX-Trigger

or

HX-Trigger-Name

header (so I could pass it along to the template being rendered).

Since the

target

works I figured there's something I'm missing with

source

or maybe it's the wrong keyword.

Shoot. I'm looking in the code. It looks like

hx-trigger

is handled in

handleAjaxResponse

(line 2028 in whatever branch I've got open)

But it's not being called in

htmx.ajax

which means the

hx-trigger

response header will work if you're using an

hx-get=""

attribute (or similar) but not if you're calling

htmx.ajax

directly.

(same goes for hx-trigger-name. It's a response header that's not being processed by htmx.ajax)

Odd that

HX-Target

works, but that

HX-Trigger

doesn't.

Well that explains that... would be handy. Otherwise I guess specify the

source

in the context object is a bit pointless

I've got to step away for a bit but I'll be back later.

Sounds good.

🙂

hi guys

im on htmx.ajax too

i saw in the issues that there is the same question than me : how to add the swap parameter in the htmx.ajax ? i mean to tell 'outerHTML' . Is it possible ?

I think htmx.ajax just sends the request, but does not handle the response. So, there’s no swap. That would be the request handler.

I’d really like to have a public

htmx.swap

function that handles the cases that you and @future-table-82610 have raised. But so far, that’s still on the back burner.

so, when i call "content A" by a javascript way, and if from "content A" there is some new htmx call, they fwont work because they are not processed/discovered at the start