Hi ViggieSmalls. Have you looked into the output of Chrome devtools? Maybe CORS error or something like this blocks loading this.

Hi, i was just typing a question on SO, but i think i answered myself there: i want to implement a textbox which fetches suggestions on user input via hx-get and sends the content on form submit via hx-post. I was puzzled how to combine that on a single element. Then i realized that the get belongs to the input and the post to the form, so nothing to combine there. Is this a common use case? Should it be a bit more prominent in the docs? I spent some hours with that (but I'm slow anyway...)

sounds right, a good example for the docs would be welcome

I'll provide mine when it's done. It's basically the search example in the hx-trigger docs surrounded with a form which has its own trigger and hx-post. BTW, there is a typo in the docs. The example's target is

hx-target="#search-results"

while the descriptive text talks about

response-div

. Also the url is not the same. I'd suspect a copy&paste error. I'd send you a pr on github for the docs if you want.

thx

There is no error mesage raised. I guess I need to find a method to evaluate the javascript, not simply add the

script

tag :/ dont't know if that's safe though

Here's my example:

<form hx-post="/add-item" hx-trigger="submit">
    <input name="search"
        hx-get="/search-items" 
        hx-trigger="keyup changed delay:100ms" 
        hx-target=".options"
        hx-include="[name='search']"
    />
    <div class="options"></div>
</form>

This issues a

GET

-request when the user is typing like the existing example in the docs. Additionally, a parameter

search

is added to the request, which contains the text the user has entered into the

input

like so:

/search-items?search=<text>

. The response is simply added to the

div.options

. If the user submits the form (i. e. by pressing enter), the post request defined in the outer

div

is issued. Feel free to use it in the docs 😆 I'd also like to hear some suggestions for this, I'm quite new to htmx and like to improve! The

hx-include

references to it's own value, which looks a bit odd. This example lacks the option to click on one of the search results and copy it's value to the

input

. Working on that next.

in theory you shouldn't need that `hx-include`: an input should include its own value

That's correct, i just removed it and it works the same. I also thought i got that from the docs, but i'm quite sure i did that in the first place and it didn't work... 🤷 Thanks!

a very similar example is present in the ██████ 🙂

This is the exact example i derived mine from 🙂 I even submitted a pull request because thete is a typo there.

Any ideas on how to execute the javascript that comes from a hx-get response? 😕

Without testing, there is a call command in hyperscript to call JavaScript functions. Maybe you can attach an event handler to the response of your

hx-get

?

Does it not get executed automatically?

inline javascript will execute. Loading a separate javascript file will not because there is no way to guarantee it executes serially, the way it does "normally". The work around is to load the javascript file up front and then invoke functions within a script tag, or to use the

HX-Trigger

header to trigger an event (my preferred approach)

I will investigate this issue more for the next release of htmx

I wonder if anyone has run across this issue with history cache and back/forward buttons. I have some hx-get actions on pages to open modals (menus etc). When I navigate to another page and then go back, the modals are pulled out of the cache.

so you open a bunch of modals, close them, navigate to another page, then click back, all the modals re-open

even setting hx-push-url="false" on the modal hx-get buttons does nothing

I've set historyCacheSize: 0 as I've never found a work around for this, but it would be nice to have so back/forward don't trigger full page loads

I've also tried deleting the cache in localStorage between code changes

is there an hx- attribute that can be used to say "do not cache this action ever"?

(or hx response header, whatever works)

ok so looks like the issue isn't the modal hx-get : looking at htmx:beforeHistorySave setting hx-push-url="false" makes sure it's not cached. The issue was that the modal was hidden (with alpine x-show) and re-loading the page from cache ignores the x-show state. Correct solution is to remove the modal element completely.

also noticed this with any use of alpinejs x-show : htmx will re-show the element when pulling from cache. Better to use x-if with template or $el.remove() or whatever and remove the element from the DOM.

I guess what might be a nice enhancement/extension would be to have an hx- directive to exclude an element from the cache, so you can do something like hx-cache-ignore. Otherwise needs a lot of hacking around when using client-side JS with alpine or similar.

if you can develop a pattern here I'd be happy to take a look at integrating it w/ the library

It might be something alpine specific, perhaps need to hook into the htmx:historyRestore event

I have had to hook into that event frequently to undo changes to the DOM made by javascript libraries

it's just one of those ugly areas unfortunately, I will try to think more about it