How do you stop Javascript from a <script> block which has been removed after an AJAX call?

[josephernest]

Hi,
Let' say I click on a <a hx-get... link, and HTMX does an AJAX call, then replaces a part of the DOM, for example #container's innerHTML.

Let's say this new HTML code contains a <script>setInterval(function () { alert(); }, 5000);</script> block. It will be executed.

Then you click on another link, and #container is now replaced again by something else. This <script> is no more there in the new HTML content.

Question: does HTMX automatically stop the setInterval from running? If so, how?

[josephernest]

Test with index.html:

<script src="https://unpkg.com/htmx.org@1.8.0"></script>
<div hx-get="page2.html" hx-swap="outerHTML" hx-push-url="true">Click me</div>
HELLO

page2.html:

<div>
Haha
<script>setInterval(() => { console.log(Date.now()); }, 1000);</script>
</div>

If you load index.html, and click "Click me", then the fragment page2.html is loaded in the DOM, and the script is executed.
The browser URL bar shows now page2.html.
When you browse "history back", you return to index.html, but you can see that the setInterval is still running (see console).

What's the standard HTMX way to limit the action of a <script> to the page where this script belongs, and automatically stop these scripts (containing setTimeout or setInterval or similar continuous-running code) when we browse to another page?

Thanks in advance and congrats again @1cg @bencroker @benpate for HTMX!

[bencroker]

I don't believe htmx does anything to stop scripts from running (why would it!), but you can stop and clear intervals any time using JS.

setInterval() returns an interval ID, which you can then pass to clearInterval():

let intervalId = setInterval(() => {}, 1000);

// ...

clearInterval(intervalId);

[josephernest]

Yes @bencroker. What's the best practice in HTMX when we load a HTML fragment containing a <script>: where should we do the cleaning (e.g. clearInterval) when we navigate from one page to the other, or when we go back in history?

As an example, the library unpoly seems to implement this with "compilers" in which you provide a function that does the cleaning

up.compiler('.current-time', function(element) {
  let update = () => element.textContent = new Date().toString()
  setInterval(update, 1000)
  return () => clearInterval(update)
})

What's the best practice for this with HTMX?

[bencroker]

I don't know that there is a "best practice", I've never personally come across this use-case before. Maybe someone else here has?

[David-Guillot]

Hi @josephernest ,

I am no official htmx voice, but I can tell you that in general, in the context of web pages that get partially replaced (by htmx or anything else), Javascript needs to get managed at the page level, not the block level. Only that will enable you to achieve page-wide Javascript behavior (making components communicate with each other, interact with behaviors triggered by elements that don't exist anymore, etc.).

The way I do it is using StimulusJS controllers that apply behaviors to page parts and that I trigger using htmx events. In the case of a setInterval(), defining a Stimulus controller on your #container would allow you to store the interval ID to the Stimulus controller and then be able to clear it by triggering a Stimulus controller method on the htmx event of your choice (onBeforeSwap, onLoad, etc.).

Maybe there is an easier way to tackle the specific issue you're facing, but the approach I'm suggesting here allowed me to handle way more complicated stuff without more than 5 minutes of work every time, because it just always works.

[benpate]

I'm making a social cms, where the primary use case is viewing/browsing posts, and the secondary use case is creating/uploading them. Here's what I do -- though I'm sure others will have solutions that fit their needs better.

• Most pages need the same small subset of front-end Javascript (~35k of tabs, accessibility, and a couple other behaviors that I could probably optimize) so these files are all included on the main page wrapper/header/footer. Most of the interactivity is provided by HTML Fragments that pop in and out of this basic scaffolding with no problem.
• Admin pages that need more (like drag-n-drop or wysiwyg) are "special" and I just use a regular href to reload the window when I get to them. This is a pretty low cost for a relatively low frequency operation, and it keeps the rest of the pages light.

So, for my purposes anyway, it's not too much work to just plan ahead and always load all the javascript you'll need, then pare back the heaviest exceptions on a case-by-case basis.

[josephernest]

Out of curiosity @benpate, do you know an open-source project (or large-enough tutorial) with a few different pages + AJAX navigation, using only HTMX or Vanilla JS that would showcase how JS is called for each different page?

I'm looking for inspiration :) about how to manage the JS parts of the different pages (HTML fragments loaded via HTMX)

[David-Guillot]

When we have many pages (many pages, but navigated with AJAX / HTMX from a single page by replacing HTML fragments, i.e. without reloading a full page), how do you organize the scripts for each "page"?

With "page" I'm talking from a technical perspective (an HTML document loaded natively by a browser without using Fetch or XHR), not a user perspective (I like to use "screens" to talk about what users see). And from a technical perspective, each "page" needs to hold a Javascript "app" that's able to handle any JS behavior triggered by any "screen" that would possibly be displayed during the user journey through this page. This means, if your use-case is to simulate an SPA, then you have only one page, so only one JS app.

And this is why I like Stimulus: it allows you to define an "app" (which can live on website-level or on page-level) that holds every possible JS behavior that could be triggered from the "page" loading the "app". Behaviors are added as "controllers" (JS classes), so the "app" is composable. This way each "app" contains only the JS code that it will ever need (which is all JS code if your use-case is the SPA thing).

So what I do is create a JS file for each "page" ; this JS file contains only a Stimulus app that, by default, contains no controller (no behavior). And when I want to add a JS behavior to my "page" (whatever the "screen"), I add a controller to my Stimulus app.

FWIW: my use-case is not the SPA thing, because I prefer users seeing a "page change" once in a while than users loading 500kB of JS code that they will not need because the screen they will use today is a simple one.

Hope that was clear 😉

[benpate]

Hey @josephernest - I'm sorry, I wish I did have a good example for you. I'm frantically working on something I hope will be a good example to pour through, but it still takes too much work for "non-me" people to set up.

Htmx is still very new, so welcome to the bleeding edge :) I will echo what some others have already said here, that there's not really a "best practice" for this, just different emerging patterns that work with different people's code. I also agree with @David-Guillot that it's better to have a page refresh once in a while, than it is to load a huge amount of client-side code up-front.

To propose another possible solution to your original question, Htmx and Hyperscript both work hard to connect snippets of code to a specific DOM node. You'll see many spots in their source codes where they check to see if their "owner" DOM node still exists. If it does, yee-haw, continue processing. If not, then they halt the process. Here's one example in the SSE extension; it's a pattern copied from other parts of htmx.

Since you're writing your own Javascript, what if you tried something like this in your own code? Here's a very sloppy example to get you started, though I'm sure a little you could make this much prettier with a little more thought.

function myProcess(nodeId, otherArgs) {
  return function() {
    var node = document.getElementById(nodeId);

    // Break out of the loop if the origin node no longer exists.
    if (node == nil) {
      return;
    }

    // Fall through to do the thing..
    ...

    // Then queue up another run in 1 second...
    setTimeout(myProcess(nodeId, otherArgs), 1000);
  }
}

// Start the first run here...
myProcess("the-node-id", otherArgs)();

[josephernest]

Thanks @benpate for these ideas!

[josephernest]

@David-Guillot Thanks for these ideas! Yes very clear 👍
You're right, it's important to have precise terminology: "page" for technical pages (no Fetch or XHR), and "screens" for what users see. In my case I have nearly a SPA, a few non-AJAX pages (that we can forget here), and 1 main "page" with 10 "screens" (each screen is loaded with HTMX by updating HTML fragments of the page). Thus with your technique, I should have 1 JS for this main page. How to make that some JS is called after a screen is loaded and after a screen is quitted?

main.js

function screen1_load() {
}
function screen1_clear() {
}
function screen2_load() {
    console.log("screen2 loaded");
    screen2_interval = setInterval(() => { console.log("repeat"); }, 1000);  // in which namespace should we put screen2_interval?
}
function screen2_clear() {
    clearInterval(screen2_interval);
}

index.html

<script src="https://unpkg.com/htmx.org@1.8.0"></script>
<script src="main.js"></script>
<div hx-get="screen2.html" hx-swap="outerHTML" hx-push-url="true" hx-after-swap="screen2_load();" hx-after-unload="screen2_clear();">Go to screen2</div>

screen2.html

<div>This is screen2</div>

Here is the naive way I was thinking about: ask HTMX to launch screen2_load() when this screen has been swapped into the DOM, and launch screen2_clear() when we quit this "screen" (case #1: we swap the DOM by going to another "screen", case #2: browser history back). My pseudo-code hx-after-swap="screen2_load();" is not correct, would you do like this:

document.addEventListener('htmx:afterSwap', e => {
    if (e.detail.pathInfo.requestPath == 'screen1.html')
        screen1_load();
    if (e.detail.pathInfo.requestPath == 'screen2.html')    // there is probably a nicer way to handle this... 
        screen2_load();
});

?

How would you handle the "quit screen" cases to call screen2_clear()? (either because going to another screen or because browser history back has been pressed)

[David-Guillot]

Hi there, sorry for the delay, it's a quite busy week...

Yes clearly you'd have to rely on an event listener defined in your page-level JS, which would have the same role as your backend HTTP router:

• On server: URL x has been asked, let's trigger its HTTP controller and render its HTML template
• On JS side: screen x has been loaded, let's trigger/initialize its JS behaviors

As for the "screen unload" detection, you could leverage the fact that your page-level JS has a global knowledge of all its screens, and do the following when a screen loads:

1. Call a function that initializes the screen behaviors, like we said earlier
2. Iterate on all other screen to call their "unload" function (one per screen, that may be empty most of the time but could do the job of unplugging a setTimeout for example)

And that is one more reason why I like StimulusJS: its controllers, that you can very easily plug on "screens", have lifecycle callbacks, among which disconnect() does precisely what I just described.

[vb8448]

Hi,
i know it's an old discussion but, just in case someone else want a more "simple" way to init/destroy object, this is what i'm doing using alpinejs:

      <div class="card-datatable table-responsive"
       x-data="{
        init() {
           console.log('init datatable');
           $('#permissions-list').DataTable();
         },
         destroy() {
           $('#permissions-list').DataTable().clear().destroy();
         }
       }"
      >
       <table class="table" id="permissions-list">
    .........