otoh, did this error message help you find some problems?

In this particular case, no. The behaviour is how I want it and correct. The error logging has helped a ton already on a bunch of other places, where I was telling htmx about non-existing spinners etc.

hmm, so maybe we need a way to supress this error then

can you kick the error to use time vs parse time?

it would still be an error if you tried to trigger the behavior before that selector existed right?

exactly

can I see the full stack trace?

both usages of this method look like use time to me

but who knows, my brain is absolute jelly right now

I am inclined to believe you, because I learned long ago that if it's a toss up between a bug in htmx and my code... it's my code 99.9999999% of the time

Although... this behaviour worked fine with 1.6.1 and still works fine with 1.7.0 ... i.e. the hx-include vals get's submitted to the server like it should at use time

Ha. I guess that stacktrace doesn't help you much, since it's the minified version

Lemme chuck in the unminified version

Hmmm... you know... I know what's happening. It IS making a call initially, without those values being present, on page load essentially. The user selecting a dropdown option later is. 2nd call, at which time the values are there and it's fine

Like I said, toss up between htmx and my code ... 🤦‍♂️

It happens to be fine that the values aren't present on page load.. which is why the app works as expected.

I guess in my case, an opt-out of the checking would be useful, but I'm not sure it's worth it, cause probably no-one else will have the need for this

I use alpine and htmx and for some reason never clued in that I could use x-bind with htmx attributes. But if course you can! Gonna go clean up some code now 😎. Thank you!

I found that binding paried very well with the id magic

since you could make a target refer to itself and then componentize it

OK, let's think about it some more

I pacified htmx by just including a selector of something that is always available 😁 👍

(Read: I tricked htmx to be artificially tolerant of my already weird code)

Quick question. If I want to submit a form then I put

hx-get="/search"

on the

<form>

tag. If I want to snapshot the page and add a new url to the history then I put

hx-push-url="true"

on the

<form>

tag. When I do I don't get anything in my browser's url history. Are these two compatible with each other when dealing with a

<form>

tag? I'd expect my form's

get

representation to be appended to the current url and that pushed onto the form history. I'm must be missing something, eh?

change the hx-post to an hx-get

I did try that, but no change, the url won't budge

I tweaked my original message to remove the

hx-post

red herring. Thanks for noticing that.

Just to ensure I am minimally capable of using htmx, I moved the

hx-get

to one of the

<input>

tags, and then I did get the browser url history that I expected. It seems like there is a hidden "if the

hx-get

is on a

<form>

tag then ignore `hx-push-url`" logic in htmx.

In the case of the

hx-get

being on the

<input>

htmx did update the browser's url history, and it also included the button's

name

and

value

in the url it pushed onto the browser's history, so you can kind of see it pushing a url with multiple key/value pairs, just not an entire form's worth.

I should offer my use case for wanting an entire form to be stuffed into the url. In my day job I often craft UIs with multiple form elements that allow users to build semi-complicated queries. Nothing too crazy, but routinely 2+ different "where" clauses for a sql statement. I'd like to be cool and hateoas, so when any of the form inputs change, the entire form is posted, and the resulting url is pushed onto the browser history. Then if they hit the back button, or bookmark the url, they can reproduce the form inputs, and so reproduce the search criteria. The example of a single

<input>

element is cool, but these UIs routinely have 2+ inputs the users can work with.